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

["Daniel P. Berrange" <berrange@redhat.com>]

On Wed, Feb 28, 2007 at 09:27:30PM +0000, 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  -=|