Re: [Qemu-devel] Re: PATCH: Secure TLS encrypted authentication for VNC

[Daniel P. Berrange]

On Tue, Jun 03, 2008 at 11:27:58PM +0200, Peter Rosin wrote:
> Stewart Becker skrev:
> >On Tue, 2008-06-03 at 12:31 +0200, Peter Rosin wrote:
> >>Hi!
> >>
> >>Sorry for the response to this old post, but since it seems to be the
> >>best reference for the VeNCrypt protocol on the web, I don't feel too
> >>bad. Hopefully I got the message-id correct so that this post is
> >>properly linked.
> >>
> >
> ><snip>
> >
> >>I would like to point out that vencserver seems to be sending an
> >>extra U8 (== 0x01. Is that a boolean? 0x00 means failure?) before
> >>the SSL/TLS handshake is started. The QEMU implementation does
> >>this also, so the bug is clearly in this "spec". This also affects
> >>sub-types 258, 259, 260, 261 and 262.
> >>
> >>
> >>Cheers,
> >>Peter (not subscribed)
> >
> >Peter,
> >
> >It's been a while since I looked at it, and don't have time immediately
> >to check it in detail, but I think that this is the SecurityResult
> >message as detailed in section 6.1.3 of the RFB specification.
> >Re-reading it, I could probably have been more clear in my mail to Dan
> >about where the VenCrypt extension rejoins the RFB protocol.  The reason
> >that I put this in the extension code instead of the "main" VNC code is
> >that only the extension knows whether the success of failure message
> >should be sent.
> 
> I don't think it's the security result, because the security result
> comes after the TLS handshake. This is apparent if you consider the
> variants based on Vnc-Auth and Plain where the security result comes
> after the authentication and the authentication is clearly inside the
> encrypted tunnel. But the security result comes inside the TLS tunnel
> for the variants based on None as well, that's a fact. Another piece
> of evidence that it is not the security result is the fact that the
> security result is U32 and this "missing element" is a U8. Pretty
> strong hint in my book :-)

It is not *the* security result, rather it is an intermediate result. 
Basically the client has chosen to do VeNCrypt auth and has sent its
request for the particular VeNCrypt sub-type it wants to use. This U8
is basically a  boolean indication of whether the server accepts the
clients choice of sub-type. If it accepts it, then the TLS handshake
will proceed, the sub-type specific auth process takes place and you'll
eventually get the final security result. If the server rejected the
choice of sub-type, then it will be closing the connection anyway. So
this u8 doesn't technically add any security to the protocol - it could
have been left out and things would have worked just as well.

Regards,
Daniel.
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|