Re: Register libvirtd ports with IANA ?

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

 



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.

I think we should wait on Dan's stuff before changing this.

  I still want to be able to build without the dependancy and optionally
allow unencrypted connections.

Rich.

[1] From http://www.ietf.org/rfc/rfc2817.txt:

  At the Washington DC IETF meeting in December 1997, the Applications
  Area Directors and the IESG reaffirmed that the practice of issuing
  parallel "secure" port numbers should be deprecated. The HTTP/1.1
  Upgrade mechanism can apply Transport Layer Security [6] to an open
  HTTP connection.

--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.  Registered in
England and Wales under Company Registration No. 03798903

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


[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]