Re: [rfbproto] VeNCrypt security type specification
I was unable to get in touch with Adam, so I have commit the patch more or less as-is. Regards -- Pierre Ossman Software Development Cendio AB http://cendio.com Teknikringen 8 http://twitter.com/ThinLinc 583 30 Linköpinghttp://facebook.com/ThinLinc Phone: +46-13-214600http://plus.google.com/+CendioThinLinc A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? signature.asc Description: PGP signature -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: #149; 3 signs your SCM is hindering your productivity #149; Requirements for releasing software faster #149; Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] VeNCrypt security type specification
On Fri, 04 Nov 2011 13:03:02 +0100, Adam Tkac wrote: Pierre just poked me about merging VeNCrypt specification into the RFB proto. I'm happy with the latest version, Dan, could you please tell us if it is fine from your point of view? Thanks in advance! Regards, Adam This thing has lingered for way too long. Better we commit this version and do improvements later than have nothing at all. Adam, do you think you could clean up the SASL section and reformat the patch with a commit message and signed off line? Rgds -- Pierre Ossman Software Development Cendio AB http://cendio.com Teknikringen 8 http://twitter.com/ThinLinc 583 30 Linköpinghttp://facebook.com/ThinLinc Phone: +46-13-214600http://plus.google.com/+CendioThinLinc A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? signature.asc Description: PGP signature -- ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] VeNCrypt security type specification
On Thu, Mar 27, 2014 at 10:43:15AM +0100, Pierre Ossman wrote: On Fri, 04 Nov 2011 13:03:02 +0100, Adam Tkac wrote: Pierre just poked me about merging VeNCrypt specification into the RFB proto. I'm happy with the latest version, Dan, could you please tell us if it is fine from your point of view? Thanks in advance! Regards, Adam This thing has lingered for way too long. Better we commit this version and do improvements later than have nothing at all. Its so long ago that I don't recall what version we're talking about. Might as well commit it and fix any problems afterwards than letting it linger. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] VeNCrypt security type specification
On 05/19/2011 11:39 AM, Pierre Ossman wrote: On Tue, 20 Jul 2010 10:31:09 +0200 Adam Tkacat...@redhat.com wrote: Next revision of VeNCrypt spec is attached. Any chance of getting this documentation effort restarted/finished? Would be nice to have things finalised as this is a popular extension. :) Pierre just poked me about merging VeNCrypt specification into the RFB proto. I'm happy with the latest version, Dan, could you please tell us if it is fine from your point of view? Thanks in advance! Regards, Adam -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] VeNCrypt security type specification
On Thu, Jul 15, 2010 at 04:09:59PM +0100, Daniel P. Berrange wrote: Hello Dan, thanks for your input. On Thu, Jul 15, 2010 at 04:45:40PM +0200, Adam Tkac wrote: +Following VeNCrypt subtypes are defined in this document: + +=== === === +CodeNameDescription +=== === === +257 TLSNone TLS encryption with no authentication +258 TLSVnc TLS encryption with VNC authentication +260 X509NoneX509 encryption with plain password +261 X509Vnc X509 encryption with VNC authentication +=== === === We should list all codes in this doc, even if they aren't described, so that we have a full record. There are 9 so far Included in the version 2 of the patch. +VeNCrypt subtypes +~ + +This section applies to all VeNCrypt subtypes. All those subtypes +use TLS-encrypted stream and server use anonymous X509 +certificate (subtypes with the TLS prefix) or valid X509 certificate +(subtypes with the X509 prefix). When session is negotiated, all +further traffic is send via this encrypted channel. + +When any of the VeNCrypt subtype is decided, server tries to setup +TLS session (load certificates etc.). I think this could be clarified a little, since it doesn't make it clear whether the u32 byte confirm from the server is sent in clear or under TLS. We should say something like After receiving the u32 confirmation of the VeNCrypt subtype, the TLS handshake is performed between the client server. If the handshake is unsuccessful the connection must be closed and no further RFB protocol messages attempted In my opinion both clauses are clear enough but yours is more verbose so I used it instead of mine. + After that it sends back to client +if it was successful: + +=== === === === +No. of bytesType[Value] Description +=== === === === +4 ``U32`` status: +.. 0 OK +.. 1 failed +=== === === === + +In case of failure, server sends a string with detailed description and +closes the connection: + +== = == +No. of bytes Type Description +== = == +4 ``U32`` *reason-length* +*reason-length*``U8`` array *reason-string* +== = == This isn't correct. There is no confirmation of TLS handshake completion at the RFB protocol level. After the TLS handshake completes, the RFB protocol proceeds to the auth subtype. Right you are, I've completely removed this clause. Patch which incorporates your suggestions is attached. Regards, Adam -- Adam Tkac, Red Hat, Inc. VeNCrypt security type specification. VeNCrypt security type specification was obtained directly from code of the original implementation, the VeNCrypt project (http://sourceforge.net/projects/vencrypt). Signed-off-by: Adam Tkac at...@redhat.com Index: rfbproto.rst === --- rfbproto.rst(revision 4086) +++ rfbproto.rst(working copy) @@ -373,6 +373,7 @@ 1 `None`_ 2 `VNC Authentication`_ 16 `Tight Security Type`_ +19 `VeNCrypt`_ === === Other registered security types are: @@ -384,7 +385,6 @@ 6 RA2ne 17 Ultra 18 TLS -19 VeNCrypt 20 SASL 21 MD5 hash authentication === === @@ -603,6 +603,139 @@ Note that the `ServerInit`_ message is extended when the Tight security type has been activated. +VeNCrypt + + +The VeNCrypt security type is a generic authentication method which +encapsulates multiple authentication subtypes. Every VeNCrypt subtype +creates TLS stream so all VNC traffic is encrypted. + +After VeNCrypt security type is selected server sends the highest +version of VeNCrypt it can support. Although two versions exist, 0.1 +and 0.2, this document describes only newer version 0.2. + +=== === === === +No. of bytesTypeValue Description +=== === === === +1 ``U8`` 0
