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