webSocketsHandshake is wrongly detected over slow connection

[matti]

Describe the bug

#define WEBSOCKETS_CLIENT_CONNECT_WAIT_MS 100

...

ret = rfbPeekExactTimeout(cl, bbuf, 4,
                               WEBSOCKETS_CLIENT_CONNECT_WAIT_MS);
if ((ret < 0) && (errno == ETIMEDOUT)) {
  rfbLog("Normal socket connection\n");
  return TRUE;
} else if (ret <= 0) {
  rfbErr("webSocketsHandshake: unknown connection error\n");
  return FALSE;
}

from

libvncserver/libvncserver/websockets.c

Line 129 in 4d65ec4

WEBSOCKETS_CLIENT_CONNECT_WAIT_MS);

To Reproduce
delay socket connection by 101ms --> connection is identified as a websocket connection.

Expected Behavior
socket connection is not detected as websocket connection even if the link is slow

[bk138]

Thanks! Do you maybe actually mean "connect with ws/wss, delay by 101ms -> connection identified as normal if though it's not?"

[matti]

No, the opposite. Every time my normal socket client fails to send "RFB ..." in 100ms, it is detected as a wesocket client

…

On 5. Aug 2020, at 22.27, Christian Beier ***@***.***> wrote:  Thanks! Do you maybe actually mean "connect with ws/wss, delay by 101ms -> connection identified as normal if though it's not?" — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[matti]

I have a proxy which detects x11vnc server sent RFB 003.008\n and I add sleep(1) before the client sends its reply of RFB 003.008\n back, then x11vnc (libvncserver) thinks that the client is websockets.

[bk138]

I you could share some proof-of-concept code, that'd be nice! Thanks!

[bk138]

Also, it would help which code path is actually taken, a backtrace or printf-debugging is sufficient.

[matti]

can you give your email and I'll share a screencast? that would be easiest for me

[bk138]

A log file, maybe annotated in between with what happened, would be most helpful. You can post that here :-)

[matti]

I don't understand how a logfile that says webSocketsHandshake failed from x11vnc helps here?

…

On 7. Aug 2020, at 15.43, Christian Beier ***@***.***> wrote:  A log file, maybe annotated in between with what happened, would be most helpful. You can post that here :-) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[bk138]

I believe you that you encounter this bug, so no need for screencast :-) Open question: How would I be able to reproduce this reliably?

[matti]

Add sleep(1) between client connects server accepts server sends RFB 3......\n sleep(1) client replies with RFB 3.....\n because of the line of code I sent in the first post where there are timeouts to detect websockets, the client is detected as websockets and it fails becauee client is socket.

…

On 8. Aug 2020, at 12.02, Christian Beier ***@***.***> wrote:  I believe you that you encounter this bug, so no need for screencast :-) Open question: How would I be able to reproduce this reliably? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[bk138]

Thanks! I reckon you have the sleep on the client side?

[matti]

Yes on client (or more specifically in the proxy) and to recap: the sleep is just repro this "slow client" problem

…

On 9. Aug 2020, at 9.51, Christian Beier ***@***.***> wrote:  Thanks! I reckon you have the sleep on the client side? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[matti]

this still happens

[matti]

like isn't this a very straight forward bug? the handshake expects something to come in within 100ms or it changes protocol - on a slow network this always causes protocol change