Re: Register libvirtd ports with IANA ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]