On Mon, Jul 19, 2010 at 02:08:30PM +0200, Adam Tkac wrote: > +VeNCrypt > +--------
> +Following VeNCrypt subtypes are defined in this document: > + > +=============== =============== ======================================= > +Code Name Description > +=============== =============== ======================================= > +256 Plain Plain authentication (should be never used) > +257 TLSNone TLS encryption with no authentication > +258 TLSVnc TLS encryption with VNC authentication > +259 TLSPlain TLS encryption with Plain authentication > +260 X509None X509 encryption with plain password > +261 X509Vnc X509 encryption with VNC authentication > +262 X509Plain X509 encryption with Plain authentication > +263 TLSSASL TLS encryption with SASL authentication > +264 X509SASL X509 encryption with SASL authentication > +=============== =============== ======================================= > + > +After that client selects one VeNCrypt subtype sends back number of that > +type. > + > +=============== ======= =============================================== > +No. of bytes Type Description > +=============== ======= =============================================== > +1 ``U32`` Selected VeNCrypt subtype > +=============== ======= =============================================== > + > +If client supports none of the VeNCrypt subtypes it terminates > +connection. > + > +When subtype is selected authentication continues as written in particular > +VeNCrypt subtype description. > + > +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. > + > +After receiving the U32 confirmation of the VeNCrypt subtype, > +the TLS handshake is performed between the client and server. > +If the handshake is unsuccessful the connection must be closed > +and no further RFB protocol messages attempted. There's one exception here. With Plain (256) subtype no TLS handshake is done, it is completely cleartext. All the others do a anonymous of x509 based handshake. > + > +Note about TLS parameters, like algorithm and key length. VeNCrypt > +doesn't enforce any restriction, setting should be determined by local > +security policy on client, respective server, side. This also applies > +for validity of the server certificate, client side can decide if it > +wants to accept invalid server certificate. > + > +In case TLS negotiation is not successful, detailed information of failure > +can be obtained from underlying TLS stream and both sides must close the > +connection. > + > +In case TLS negotiation is successful and TLS channel is estabilished, > +VeNCrypt authentication can continue. > + > +If VeNCrypt subtype has None suffix then authentication is successful, > +both sides can continue to `Initialisation Messages`_ section. Shouldn't this say that it continues to the 'SecurityResult' message ? Actually we should probably just link to section `None`_ since has a different sequence depending on RFB version. > +If VeNCrypt subtype has Vnc suffix, then authentication continues with > +the standard `VNC Authentication`_ method. > + > +If VeNCrypt subtype has Plain suffix, then authentication continues and > +client sends the username and password in the following form: > + > +=============== ============= ========================================= > +No. of bytes Type Description > +=============== ============= ========================================= > +4 ``U32`` Username length > +4 ``U32`` Password length > +Username length ``U8`` array Username > +Password length ``U8`` array Password > +=============== ============= ========================================= > + > +After that server verifies if supplied credentials are correct and > +continues with the *SecurityResult* message. Should we declare what happens for RFB version < 3.8 that don't have the securityresult message support ? 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 :| ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
