Re: [Qemu-devel] Re: PATCH: Secure TLS encrypted authentication for VNC
On Wed, Feb 28, 2007 at 09:27:30PM +, S. I. Becker wrote: 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. 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. If there's any formal doc describing the VeNCrypt auth system in the same style as the primary RFB protocol doc[1] that'd be very helpful. I basically figured out the VeNCrypt protocol by reading the code and the few mailing list notes about it. I've validated inter-operability of the QEMU patches against the VeNCrypt viewer command, and validated my GTK-VNC patches against the VeNCrypt server so pretty sure I've got the normal cases correct. I've also tested a variety of error scenarios and delibrate violations of protocol to ensure correct clien rejection. It would still be useful to validate the code against a formal spec though to ensure I didn't miss an edge case somewhere. Regards, Dan. [1] http://www.realvnc.com/docs/rfbproto.pdf -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: PATCH: Secure TLS encrypted authentication for VNC
Daniel P. Berrange wrote: If there's any formal doc describing the VeNCrypt auth system in the same style as the primary RFB protocol doc[1] that'd be very helpful. I basically figured out the VeNCrypt protocol by reading the code and the few mailing list notes about it. I've validated inter-operability of the QEMU patches against the VeNCrypt viewer command, and validated my GTK-VNC patches against the VeNCrypt server so pretty sure I've got the normal cases correct. I've also tested a variety of error scenarios and delibrate violations of protocol to ensure correct clien rejection. It would still be useful to validate the code against a formal spec though to ensure I didn't miss an edge case somewhere. Regards, Dan. Dan, The closest I have to a formal spec are some emails going back-and-forth between Martin Koegler and myself over what the protocol should be. I've tried to collate and format these together below. Please let me know if anything is not clear, or if you can spot any edge-cases that permit security flaws. FYI: VeNCrypt protocols and version numbers of software releases will follow a pattern: a viewer/server with a software version number of x.y.z will implement all non-obsolete VeNCrypt protocol versions up to and including version x.y. An even value for x means that the software/protocol is in development state. An odd value for x means the software/protocol is in production state. When a development protocol x.y is ready to be declared production, it will be copied as version x+1.0. This will be in tandem with a software release version x+1.0.0, which will be version x.y.z renumbered, plus a software change to communicate version x+1.0.0 as protocol number. I'd be quite interested if you make headway on the unix side of things, in particular implementing a the username/password checking part of Plain types, since I primarily have a Windows background. It's not that I won't do the unix stuff, more that I can't (or at least, find it more difficult). (FWIW, I run debian and Redhat on a couple of machines, but don't use them on anything like a day-to-day basis). The fact that someone other than myself is using VeNCrypt - particular from the the unix/Linux world - has led me to put a Help wanted ad on sourceforge for precisely this. Stewart RFB Protocol section 6.2.19 - VeNCrypt Security Type: After the VeNCrypt security type (19) is chosen, the server then sends the highest version of the VeNCrypt RFB extension it supports, as two U8s (major version followed by minor version) No. of bytesType[Value] Description 1 U8 Highest VeNCrypt major version 1 U8 Highest VeNCrypt minor version Currently the only defined versions are 0.1 and 0.2. NB ideally, servers should support all VeNCrypt versions up to and including this version, with the execption of protocol versions that have been declared obsolete. The client then responds with two U8s (major followed by minor) indicating the version to be used (anything up to and including that given by the server), or 0.0 if for some reason it can't support the protocol: No. of bytesType[Value] Description 1 U8 Chosen VeNCrypt major version 1 U8 Chosen VeNCrypt minor version In the case of 0.0 the connection is closed at this point. RFB Protocol section 6.2.19.0 - VeNCrypt Security Sub-type negotiation: The server then responds with either a single U8, 0 for indicating that the server can support the version chosen by the client or non-zero (typically 255) for failure. If non-zero, the connection is closed at this point: No. of bytesType[Value] Description 1 U8 Success/Failure Depending on the VeNCrypt version chosen and acknowledged by the server, communication continues at section 6.2.19.0.1 (VeNCrypt protocol 0.1) or 6.2.19.0.2 (VeNCrypt protocol 0.1) RFB Protocol Section 6.2.19.0.1 - VeNCrypt protocol 0.1 VeNCrypt protocol 0.1 is now obsolete, servers that show numbers higher than 0.1 need not support it. The server sends a U8 listing the number of sub-types supported. If this is zero, the connection terminates, otherwise it is followed by the sub-types it supports/permits as U8s: No. of bytesType[Value] Description 1 U8 [n] Number of supported sub-types n U8 arraySupported sub-types The sub-types are as follows: 19: Plain 20: TLSNone 21: TLSVnc 22: TLSPlain 23: X509None 24: X509Vnc 25: X509Plain The client chooses one of these by sending back a single U8, or 0 for it being unable to choose one. If 0 is sent, the connection is closed at this point: No. of bytesType[Value] Description 1 U8 Chosen sub-type If 0 is sent,
[Qemu-devel] Re: PATCH: Secure TLS encrypted authentication for VNC
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
