[Libvir] Register libvirtd ports with IANA ?
Daniel P. Berrange
berrange at redhat.com
Mon Jun 18 12:45:03 UTC 2007
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 -=|
More information about the libvir-list
mailing list