From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K3e3R-0004gj-2q for qemu-devel@nongnu.org; Tue, 03 Jun 2008 17:28:29 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K3e3O-0004bF-Gc for qemu-devel@nongnu.org; Tue, 03 Jun 2008 17:28:28 -0400 Received: from [199.232.76.173] (port=56613 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K3e3O-0004ay-AA for qemu-devel@nongnu.org; Tue, 03 Jun 2008 17:28:26 -0400 Received: from pne-smtpout1-sn1.fre.skanova.net ([81.228.11.98]:44259) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1K3e3N-0002dV-Ry for qemu-devel@nongnu.org; Tue, 03 Jun 2008 17:28:26 -0400 Message-ID: <4845B75E.4090402@lysator.liu.se> Date: Tue, 03 Jun 2008 23:27:58 +0200 From: Peter Rosin MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: PATCH: Secure TLS encrypted authentication for VNC References: <20080603103144.GA23880@sellafield.lysator.liu.se> <1212518890.7066.8.camel@ezekiel3> In-Reply-To: <1212518890.7066.8.camel@ezekiel3> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: stewart.becker@twbc.org.uk Cc: qemu-devel@nongnu.org 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. >> > > > >> 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