[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: PATCH: Secure TLS encrypted authentication for VNC
From: |
S. I. Becker |
Subject: |
Re: [Qemu-devel] Re: PATCH: Secure TLS encrypted authentication for VNC |
Date: |
Thu, 01 Mar 2007 18:21:37 +0000 |
User-agent: |
Thunderbird 1.5.0.9 (Windows/20061207) |
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 bytes Type [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 bytes Type [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 bytes Type [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 bytes Type [Value] Description
1 U8 [n] Number of supported sub-types
n U8 array Supported 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 bytes Type [Value] Description
1 U8 Chosen sub-type
If 0 is sent, then the connection here is closed. Otherwise,
communication continues as defined at:
Plain: section 6.2.19.256
TLSNone: section 6.2.19.257
TLSVnc: section 6.2.19.258
TLSPlain: section 6.2.19.259
X509None: section 6.2.19.260
X509Vnc: section 6.2.19.261
X509Plain: section 6.2.19.262
Other - typically 0, but might (maliciously) be something else:
Connection is closed
RFB Protocol Section 6.2.19.0.2 - VeNCrypt protocol 0.2
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 U32s:
No. of bytes Type [Value] Description
1 U8 [n] Number of supported sub-types
4*n U32 array Supported sub-types
The sub-types are as follows:
0: Failure
256: Plain
257: TLSNone
258: TLSVnc
259: TLSPlain
260: X509None
261: X509Vnc
262: X509Plain
Note on version 0.2 sub-types: Sub-types 1 to 255 are reserved for
standard RFB types, should it be deemed useful to have them chosen at
this point in the in the VeNCrypt protocol (choosing 19 at this point
will never be be allowed since it causes looping). Sub-types 256 to
2^31 - 1 (i.e. values with the most significant [sign] bit not set) are
reserved as "official" future VeNCrypt sub-types, and may be requested
from VeNCrypt in the same way that new RFB types may be requested from
RealVNC Ltd. Sub-types 2^31 to 2^32 - 1 (i.e. values with the most
significant [sign] bit set) may be used as "unofficial" types, allowing
the protocol to be extended without reference to VeNCrypt.
The client chooses one of these by sending back a single U32, or 0 for
it being unable to choose one. If 0 is sent, the connection is closed
at this point:
No. of bytes Type [Value] Description
4 U32 Chosen sub-type
If 0 is sent, then the connection here is closed. Otherwise,
communication continues as defined at:
Plain: section 6.2.19.256
TLSNone: section 6.2.19.257
TLSVnc: section 6.2.19.258
TLSPlain: section 6.2.19.259
X509None: section 6.2.19.260
X509Vnc: section 6.2.19.261
X509Plain: section 6.2.19.262
"Unofficial" sub-types - Any further behaviour is implementation
defined, however it is advised that any unsupported "unofficial" types
will be treated as "Other" below.
Other - typically 0, but might (maliciously) be something else:
Connection is closed.
RFB Protocol Section 6.2.19.256 - Plain VeNCrypt sub-type
If the Plain, TLSPlain or X509Plain sub-types have been chosen, the
client sends the username and password for the connection as follows:
No. of bytes Type [Value] Description
4 U32 Username Length
4 U32 Password Length
Username Length U8 array Username
Password Length U8 array Password
The server then verifies:
a) that the specified user is permitted to connect
b) that the specified username and password are valid
NB See section 6.2.19.259 or 6.2.19.262 for communication that occurs
prior to this if the TLSPlain or X509Plain sub-types have been chosen.
Communication continues with the SecurityResult message
RFB Protocol Section 6.2.19.257 - TLSNone VeNCrypt sub-type
If the TLSNone, TLSVnc or TLSPlain sub-types have been chosen, Anonymous
TLS authentication is initiated as described in the TLS protocol.
If the TLS authentication was not successful, the connection is closed.
Otherwise, all further communication takes place over the encrypted
TLS channel.
If the TLSNone sub-type was chosen, authentication continues as for the
None type described in section 6.2.1.
RFB Protocol Section 6.2.19.258 - TLSVnc VeNCrypt sub-type
TLSNone authentication takes place, as described in section 6.2.19.257,
followed by VNC authentication as described in section 6.2.2
RFB Protocol Section 6.2.19.259 - TLSPlain VeNCrypt sub-type
TLSNone authentication takes place, as described in section 6.2.19.257,
followed by Plain authentication as described in section 6.2.19.256
RFB Protocol Section 6.2.19.260 - X509None VeNCrypt sub-type
If the X509None, X509Vnc or X509Plain sub-types have been chosen, X509
certification based TLS authentication is initiated as described in the
TLS protocol.
If the X509/TLS authentication was not successful, the connection is
closed. Otherwise, all further communication takes place over the
encrypted TLS channel.
If the X509None sub-type was chosen, authentication continues as for the
None type described in section 6.2.1.
RFB Protocol Section 6.2.19.261 - X509Vnc VeNCrypt sub-type
X509None authentication takes place, as described in section 6.2.19.260,
followed by VNC authentication as described in section 6.2.2
RFB Protocol Section 6.2.19.262 - X509Plain VeNCrypt sub-type
X509None authentication takes place, as described in section 6.2.19.260,
followed by Plain authentication as described in section 6.2.19.256