Daniel P. Berrange wrote:
Having repeatedly said that we should be doing TLS encryption for VNC, I figured I ought to get down & implement it. So, in the spirit of 'release
early, release often', here is the very first cut of my patch for QEMU.
This isn't suitable for inclusion in CVS yet - I just want to put it out
for people to see / experiment with.


 - There is support for the current 'None' auth type, the standard 'VNC'
   challenge/response auth type, and finally the VeNCrypt extension which
   implements a TLS layer with several sub-auth types. Since it can now
   do any protocol version, and negotiate auth types, we should be able
to easily add more auth types if we want compatability with other RFB auth extensions from projects like UltraVNC/TightVNC/etc.
 - When choosing the VeNCrypt auth type, the client/server then negotiate
   which sub-auth type they want to use. Then they perform a standard
   TLS handshake, and if this is successful move on to do the actual
   authentication. So the actual auth data exchange, and all subsequent
   RFB protocol traffic is TLS encrypted.

 - The sub-auth types supported by VeNCrypt are:

     - Plain  - username & password - no TLS at all
     - TLS Anon + None - TLS anonymous credential exchange, followed
                         by standard 'None' auth type.
     - TLS Anon + VNC  - TLS anonymous credential exchange, followed
                         by standard 'VNC' auth type.
     - TLS Anon + Plain - TLS anonymous credential exchange, followed
                          by customer 'Plain' username/password auth type.
     - TLS X509 + None - TLS x509 cert credential exchange, followed
                         by standard 'None' auth type.
     - TLS X509 + VNC  - TLS x509 cert credential exchange, followed
                         by standard 'VNC' auth type.
     - TLS X509 + Plain - TLS x509 cert credential exchange, followed
                          by customer 'Plain' username/password auth type.

 - I did not implement any of the 'Plain' sub-auth types above. I may
   add the TLS encrtyped Plain auth types, but certainly not the clear
   text version.

 - The 3 TLS Anon subauth types use the basic diffie-hellman anonymous
credential exchange. Since there is no apriori trust relationship, this is subject to MITM attacks, so only marginally more useful than
   the existing clear text wire format.

 - The 3 TLS x509 subauth types do a full x509 certificate exchange.
This is exactly the same top security model as used in the most recent HTTPS protocol implementationss, so the mode I'd recommend.
   The server needs to be configured with a CA cert, a CA revocation
   list (to block revoked clients), and its own server cert & key.
   The server is currently setup to request a client cert and will
verify the cert against the CA cert & CRL. I need to make it possible to turn this client cert verification on/off. If you used TLS X509 + None, then a whitelist of client CNAMEs and client cert verification could be your primary auth. If you use the TLS X509 + VNC / Plain auth schemes, then client cert verification should be optional. So client programs connecting at very least
   need access to the CA Cert, and if the server does cert verification
   client programs will need to supply their own certificate too.


- If configured to use the None, or VNC auth types, any of the standard VNC viewer programs will connect and if neccessary do the challenge/response authentication just fine. If the TLS
   VeNCrypt authentication type is activated, then you will obviously
   need a client program which supports this - the VeNCrypt project
   on sourceforge supplies a vncviewer implementing this scheme.
   I am also working with Anthony Ligouri to extend his awesome
GTK VNC widget to support all the different authentication types. This widget will provide a very easy way for people who want to
   build GUI frontends around QEMU to drop in secure console support.
   I intend to integrate it in virt-manager for example.


I see that you are implementing VeNCrypt in your QEMU system. I am flattered that you should choose it. Please let me know how I can help.

Stewart Becker

Project Manager: VeNCrypt

Qemu-devel mailing list

Reply via email to