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,
