Repository navigation
Non-blocking socket not handled correctly. #610
Description
openssl/ext/openssl/ossl_ssl.c
Line 2124 in 94fb921
According to the documentation, SSL_shutdown can:
If the underlying BIO is nonblocking, SSL_shutdown() will also return when the underlying BIO could not satisfy the needs of SSL_shutdown() to continue the handshake. In this case a call to SSL_get_error() with the return value of SSL_shutdown() will yield SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE. The calling process then must repeat the call after taking appropriate action to satisfy the needs of SSL_shutdown(). The action depends on the underlying BIO. When using a nonblocking socket, nothing is to be done, but select() can be used to check for the required condition. When using a buffering BIO, like a BIO pair, data must be written into or retrieved out of the BIO before being able to continue.
I don't know if we need to explicitly handle this when in non-blocking mode or not, but I'd assume so until otherwise confirmed/checked.
Activity
rhenium commentedon Jun 6, 2023
The underlying socket is always set to non-blocking by us in
SSLSocket#initialize.That
SSL_shutdown()is not retried on error is a known issue, but I'm not sure how we're supposed to fix it.openssl/ext/openssl/ossl_ssl.c
Lines 2130 to 2136 in 94fb921
Would it be acceptable for
IOish#closeto potentially block? I have an impression it could be surprising.ioquatix commentedon Jan 25, 2024
I think it's okay.
IO#closecan block in some cases.rhenium commentedon Feb 5, 2024
I don't know about other IO, but as far as I understand TCP sockets'
#closecan only block with thesetsockopt(SO_LINGER)option.I think the blocking behavior (ensuring
close_notifyto be sent) needs the user's explicit request. Changing the default behavior can be a DoS issue as I think people usually callSSLSocket#closewithout a timeout.Perhaps we can just expose
SSL_shutdown()as a new method?ioquatix commentedon Feb 5, 2024
Maybe in the first instance we can log when it fails, and then collect data about how frequently it happens?
I think we could consider exposing
SSL_shutdownas part of #609rhenium commentedon Oct 13, 2026
#1127 adds
SSLSocket#ssl_shutdownas a public method which doesn't suppress errors. If it fails with:wait_writable, the user may retry it afterssl.wait_writable.I still think changing
#closeor#close_writeto block when they previously didn't can be a problem, so I'll leave them as-is (give up sending if the underlying TCP socket is full).