On one of our Linux VMs, using the WebSocketServer class with OpenSSL 3.5.7 to listen resulted in large numbers of this error appearing in the log:
starting websocket server on port 8008
SocketServer::run() tls accept failed: OpenSSL failed - error:0A000126:SSL routines::unexpected eof while reading
SocketServer::run() tls accept failed: OpenSSL failed - error:0A000126:SSL routines::unexpected eof while reading
SocketServer::run() tls accept failed: OpenSSL failed - error:0A000126:SSL routines::unexpected eof while reading
<message continues to repeat>
The error does not impact the function of our application, and per the OpenSSL discussion, openssl/openssl#22690, this appears to have started with OpenSSL 3.x and is a result of the remote peer abruptly closing the socket:
This usually happens when the remote peer abruptly shuts down the connection without sending a "close_notify" alert which is what you are supposed to do.
1.1.1 and earlier treated this incorrectly. In such a case SSL_read() would fail and SSL_get_error() would return SSL_ERROR_SYS - but with nothing in errno. This was actually incorrect behaviour - it should be treated as SSL_ERROR_SSL with an appropriate error in the error stack. But making that change in 1.1.1 branch was too disruptive so it was introduced in 3.x instead.
So, this behaviour on behalf of the peer has probably always been there, but you are just noticing it now because how OpenSSL reacts to it has changed.
One option for dealing with this is to set the SSL_OP_IGNORE_UNEXPECTED_EOF option. See:
https://www.openssl.org/docs/man3.1/man3/SSL_set_options.html
This causes OpenSSL to treat an unexpected eof as if the peer had closed down gracefully - but make sure you read the docs above around truncation attacks.
If you have control over the remote peer, then another option is to change the remote peer so that it closes down connections gracefully.
In our case, the problem is originating from a VM monitor that is port scanning, so we don't have the ability to change the remote peer behavior. To mute the error, we need to call SSL_set_options (or SSL_CTX_set_options) to set the option SSL_OP_IGNORE_UNEXPECTED_EOF. However, although the IXWebSocket library calls SSL_CTX_set_options for its own purposes, it does not expose the OpenSSL options in this way during the handshake. Globally setting the SSL_OP_IGNORE_UNEXPECTED_EOF is unlikely to be the correct approach, so for these sorts of issues it would be helpful to allow supplementation of the existing Openssl CTX options to client applications.
On one of our Linux VMs, using the WebSocketServer class with OpenSSL 3.5.7 to listen resulted in large numbers of this error appearing in the log:
The error does not impact the function of our application, and per the OpenSSL discussion, openssl/openssl#22690, this appears to have started with OpenSSL 3.x and is a result of the remote peer abruptly closing the socket:
In our case, the problem is originating from a VM monitor that is port scanning, so we don't have the ability to change the remote peer behavior. To mute the error, we need to call SSL_set_options (or SSL_CTX_set_options) to set the option SSL_OP_IGNORE_UNEXPECTED_EOF. However, although the IXWebSocket library calls SSL_CTX_set_options for its own purposes, it does not expose the OpenSSL options in this way during the handshake. Globally setting the SSL_OP_IGNORE_UNEXPECTED_EOF is unlikely to be the correct approach, so for these sorts of issues it would be helpful to allow supplementation of the existing Openssl CTX options to client applications.