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
Plain sockets are thread-safe with regards to different threads calling sendBytes() and receiveBytes() simultaneously.
This is not the case with SecureStreamSocket. While it seems to work most of the time, there are situations (e.g., if a TLS renegotiation takes place) where an error:0A00010F:SSL routines::bad length error is seen, indicating that there are mismatched calls to SSL_write() and/or SSL_read() in case SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE was returned previously.
A fix would be to protect SecureSocketImpl::sendBytes() and SecureSocketImpl::receiveBytes() (and probably other methods as well) with a mutex.
The OpenSSL documentation states that operations on SSL objects are not thread-safe, so these should be protected.
The text was updated successfully, but these errors were encountered:
Plain sockets are thread-safe with regards to different threads calling
sendBytes()
andreceiveBytes()
simultaneously.This is not the case with
SecureStreamSocket
. While it seems to work most of the time, there are situations (e.g., if a TLS renegotiation takes place) where anerror:0A00010F:SSL routines::bad length
error is seen, indicating that there are mismatched calls toSSL_write()
and/orSSL_read()
in caseSSL_ERROR_WANT_READ
orSSL_ERROR_WANT_WRITE
was returned previously.A fix would be to protect
SecureSocketImpl::sendBytes()
andSecureSocketImpl::receiveBytes()
(and probably other methods as well) with a mutex.The OpenSSL documentation states that operations on
SSL
objects are not thread-safe, so these should be protected.The text was updated successfully, but these errors were encountered: