From 6b55d3e74400c9f7e71739abd0dac362a5db1dc6 Mon Sep 17 00:00:00 2001 From: aliguori Date: Fri, 6 Mar 2009 20:27:02 +0000 Subject: [PATCH] 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. (cherry picked from commit adc5ec856c557f75adc60b310e5b1d38210a289c) Signed-off-by: Daniel P. Berrange Signed-off-by: Anthony Liguori Signed-off-by: Mark McLoughlin Fedora-patch: 01-tls-handshake-fix.patch --- vnc.c | 8 -------- 1 files changed, 0 insertions(+), 8 deletions(-) diff --git a/vnc.c b/vnc.c index 1d8ebe7..d6a7225 100644 --- a/vnc.c +++ b/vnc.c @@ -2105,14 +2105,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; } -- 1.6.2.5