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

[Peter Rosin]

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 :-)

Cheers,
Peter