You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The documentation for nopoll_conn_get_msg() states that the accepted socket will be non-blocking by default. This is not the case when the accepted socket has not enabled TLS.
The following line in the internal accept method states it will set non-blocking, and then it sets blocking.
* This function is design to not block the caller. However,
* connection socket must be in non-blocking configuration. If you
* have not configured anything, this is the default.
This confusing behavior has tripped up multiple co-workers of mine, including me for a time, until I fully comprehended both the websocket standard and the nopoll implementation
The text was updated successfully, but these errors were encountered:
I've gotten the same problem while non-TLS.
Could I simply move
"nopoll_conn_set_sock_block (conn->session, nopoll_false);"
from
"
/* don't complete here the operation but flag it as
* pending /
conn->pending_ssl_accept = nopoll_true;
nopoll_conn_set_sock_block (conn->session, nopoll_false);
"
out of
"
if (listener->tls_on || tls_on) {
/ reached this point, ensure tls is enabled on this
* session */
conn->tls_on = nopoll_true;
...
nopoll_log (ctx, NOPOLL_LEVEL_DEBUG, "Prepared TLS session to be activated on next reads (conn id %d)", conn->id);
This issue leaves a server using libnopoll victim for a super-easy denial-of-service attack: just telnet to the non-tls port of the server and send one character (e.g. press ctrl-c) . The nopoll thread will be waiting forever to receive a full line of text, blocking traffic on all other connections. The fix suggested above seems to work.
The documentation for
nopoll_conn_get_msg()
states that the accepted socket will be non-blocking by default. This is not the case when the accepted socket has not enabled TLS.The following line in the internal accept method states it will set non-blocking, and then it sets blocking.
nopoll/src/nopoll_conn.c
Lines 4692 to 4693 in e80b74a
This is not the case for TLS sockets, as evident by this line:
nopoll/src/nopoll_conn.c
Lines 4874 to 4877 in e80b74a
Documentation for
nopoll_conn_get_msg()
states that default is non-blockingnopoll/src/nopoll_conn.c
Lines 3034 to 3036 in e80b74a
This confusing behavior has tripped up multiple co-workers of mine, including me for a time, until I fully comprehended both the websocket standard and the nopoll implementation
The text was updated successfully, but these errors were encountered: