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 -=|