path: root/vnc.c
diff options
authoraliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>2009-03-06 20:27:02 +0000
committeraliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>2009-03-06 20:27:02 +0000
commitadc5ec856c557f75adc60b310e5b1d38210a289c (patch)
tree4d53ad321f8261bee2f8e0bcc3aa6a1390f238a3 /vnc.c
parentmonitor: Pass-through for gdbstub (Jan Kiszka) (diff)
Fix bug in TLS authentication ("Daniel P. Berrange")
This patch was previously posted here: 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 <> Signed-off-by: Anthony Liguori <> git-svn-id: svn:// c046a42c-6fe2-441c-8c8c-71466251a162
Diffstat (limited to 'vnc.c')
1 files changed, 0 insertions, 8 deletions
diff --git a/vnc.c b/vnc.c
index 67cec07a8..816923410 100644
--- a/vnc.c
+++ b/vnc.c
@@ -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;