From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1HMWKi-0000uK-US
	for qemu-devel@nongnu.org; Wed, 28 Feb 2007 16:27:32 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1HMWKh-0000tn-Fr
	for qemu-devel@nongnu.org; Wed, 28 Feb 2007 16:27:31 -0500
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1HMWKh-0000tk-9Q
	for qemu-devel@nongnu.org; Wed, 28 Feb 2007 16:27:31 -0500
Received: from moutng.kundenserver.de ([212.227.126.171])
	by monty-python.gnu.org with esmtp (Exim 4.52) id 1HMWKg-0003GO-Ol
	for qemu-devel@nongnu.org; Wed, 28 Feb 2007 16:27:31 -0500
Message-ID: <45E5F3C2.1080906@sibecker.co.uk>
Date: Wed, 28 Feb 2007 21:27:30 +0000
From: "S. I. Becker" <stewart@sibecker.co.uk>
MIME-Version: 1.0
References: <20070224165444.GB1817@redhat.com>
In-Reply-To: <20070224165444.GB1817@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: PATCH: Secure TLS encrypted authentication for VNC
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

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