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.
<snip>
- 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.
<snip>
- 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.
Regards,
Dan.
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
aka
sibecker
Project Manager: VeNCrypt
http://sf.net/projects/vencrypt
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
