diff options
author | aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162> | 2009-03-06 20:27:02 +0000 |
---|---|---|
committer | aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162> | 2009-03-06 20:27:02 +0000 |
commit | adc5ec856c557f75adc60b310e5b1d38210a289c (patch) | |
tree | 4d53ad321f8261bee2f8e0bcc3aa6a1390f238a3 /vnc.c | |
parent | 8a34a0fb03191770a77026da164f3ad589c61407 (diff) |
Fix bug in TLS authentication ("Daniel P. Berrange")
This patch was previously posted here:
http://lists.gnu.org/archive/html/qemu-devel/2009-02/msg00820.html
In the case where the TLS handshake does *not* block on I/O, QEMU
sends the next 'start sub-auth' message twice. This seriously confuses
the VNC client :-) Fortunately the chances of the handshake not blocking
are close to zero for a TCP socket, which is why it has not been noticed
thus far. Even with both client & server on localhost, I can only hit the
bug 1 time in 20.
NB, the diff context here is not too informative. If you look at the
full code you'll see that a few lines early we called vnc_start_tls()
which called vnc_continue_handshake() which called the method
start_auth_vencrypt_subauth(). Hence, fixing the bug, just involves
removing the 2nd bogus call to start_auth_vencrypt_subauth() as per
this patch.
vnc.c | 8 --------
1 file changed, 8 deletions(-)
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6719 c046a42c-6fe2-441c-8c8c-71466251a162
Diffstat (limited to 'vnc.c')
-rw-r--r-- | vnc.c | 8 |
1 files changed, 0 insertions, 8 deletions
@@ -2098,14 +2098,6 @@ static int protocol_client_vencrypt_auth(VncState *vs, uint8_t *data, size_t len VNC_DEBUG("Failed to complete TLS\n"); return 0; } - - if (vs->wiremode == VNC_WIREMODE_TLS) { - VNC_DEBUG("Starting VeNCrypt subauth\n"); - return start_auth_vencrypt_subauth(vs); - } else { - VNC_DEBUG("TLS handshake blocked\n"); - return 0; - } } return 0; } |