[Qemu-devel] Re: PATCH: Secure TLS encrypted authentication for VNC

["S. I. Becker" <stewart@sibecker.co.uk>]

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