On Mon, Jun 18, 2007 at 01:31:15PM +0100, Richard W.M. Jones wrote:
Daniel Veillard wrote:
>On Mon, Jun 18, 2007 at 12:09:33PM +0100, Richard W.M. Jones wrote:
>>Daniel P. Berrange wrote:
>>>For the libvirtd we currently use two ports
>>>
>>> 16509 - TCP unencrypted stream
>>> 16514 - TLS encrypted stream
>>>
>>>My first thought is that we should really use consequetive port numbers
>>>eg 16510 and 16511.
>>A few comments ...
>>
>>We don't need to use two ports if we either use a "STARTTLS"-style
>>upgrading of unencrypted to encrypted connections (which is the
>>recommended way to do things instead of using two ports), or more simply
>>we just ditch unencrypted connections. They're disabled by default
>>anyway and not in any way required unless we want libvirt to build
>>without GnuTLS.
>
> Well if we can implement the detection automatically, I'm all for
> reducing
>to a single port !
I don't know if we can detect TLS automatically. I guess it may be
possible to detect the handshake message. Anyhow, the standard way[1]
to do this is to establish the connection in unencrypted mode, then (as
part of the protocol) upgrade the connection to an encrypted one.
The STARTTLS RFC is quite enlightening:
http://www.ietf.org/rfc/rfc2487.txt
but their concerns also revolve around backwards compatibility -- it
must always be possible to interoperate with non-TLS-supporting MTAs --
and that's not a problem that we have.
Upgrading connections in this way is subject to an easy
man-in-the-middle attack, unless the client and server are able to
specify in some way that they only want to talk over a secured connection.
Basically we'd need one extra packet exchange between client & server
before beginning the main protocol.
- Clients sends a single byte, which is a bitfield indicating supported
data encoding streams
1 - Plain, no encoding
2 - TLS encrypted
So if a client was happy with either it would send '3', or if it
only wanted a secure connection it would send '2'.
- Server looks at bitfield sent by client & picks its preferred
encoding. It returns a single byte indicating the encoding chosen
0 - Rejected all client requested encodings
1 - Plain, no encoding
2 - TLS encrypted
This still leaves us 6 bits to spare for future. Though if we're
paranoid we could send a u64 back & forth - the overhead is going
to the be roundtrip, not the size of data. That would give us a
nice 62 bits spare to play with in the future if we hit some really
horrible compatability problem we needed to negotiate at startup.
Dan
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules:
http://search.cpan.org/~danberr/ -=|
|=- Projects:
http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|