On Thu, Jul 15, 2010 at 04:45:40PM +0200, Adam Tkac wrote: > Hello all, > > I just finished formal VeNCrypt (v0.2) specification, proposed patch is > attached. All information was obtained directly from the original > implementation, the VeNCrypt project. > > Those pieces of the specification is missing: > 1. TLSPlain and X509Plain sub-encoding specification > - I will write it when I analyze *Plain authentication method in detail. > > 2. 0.1 version of the VeNCrypt extension > - I don't think it makes sence to waste time because I wasn't able > to find any VNC implementation which implements 0.1 version and > doesn't implement 0.2 version
Yep, I ignored the 0.1 protocol in GTK-VNC and QEMU too. > +Following VeNCrypt subtypes are defined in this document: > + > +=============== =============== ======================================= > +Code Name Description > +=============== =============== ======================================= > +257 TLSNone TLS encryption with no authentication > +258 TLSVnc TLS encryption with VNC authentication > +260 X509None X509 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 256 - Plain auth 257 - TLS anonymous + no auth 258 - TLS anonymous + VNC auth 259 - TLS anonymous + plain auth 260 - TLS x509 + no auth 261 - TLS x509 + VNC auth 262 - TLS x509 + plain auth 263 - TLS anonymous + SASL auth 264 - TLS x509 + SASL auth > + > +.. > + TODO: Define TLSPlain and X509Plain IIRC, with 'plain' a username and password pair is sent over the wire 'as is' with no special encoding. Thus auth 256 is even more horrifically insecure than VNC auth which at least obscures the the password a little. Should recommend that 256 is never used except in dev/debug. The other two plain are layering this over TLS so are reasonably secure. The two SASL options are the SASL (type=20) auth scheme layered over TLS > + > +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. > + > +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" > + After that it sends back to client > +if it was successful: > + > +=============== ======= =========== =================================== > +No. of bytes Type [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. What you have here is basically duplicating the security result message from section 7.1.2 "Once the security-type has been decided, data specific to that security-type follows (see Security Types for details). At the end of the security handshaking phase, the protocol normally continues with the SecurityResult message." > +Now client sets his TLS session parameters (like CA certificate etc.). > +In case of failure it terminates the connection. When both sides have > +TLS session parameters set, TLS negotiation can start. > + > +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 can 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. > + > +If VeNCrypt subtype has Vnc suffix, then authentication continues with > +the standard `VNC Authentication`_ method. > + > + Regards, 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
