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.
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 lengtherror is seen, indicating that there are mismatched calls toSSL_write()and/orSSL_read()in caseSSL_ERROR_WANT_READorSSL_ERROR_WANT_WRITEwas 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
SSLobjects are not thread-safe, so these should be protected.