Clarifying OpenSSL 0.9.8L Concurrency Support - Can SSL Instances Be Used By Multiple Threads If Done Non-Concurrently?
We have a multi-threaded network application
that has been using sockets for 10 years and now we're trying to secure
the application with OpenSSL 0.9.8L. Over the years, the application's
network protocols have been designed to take advantage of the duplex nature
of a single socket connection; the application concurrently reads and writes
on the same socket. The application manages the underlying socket
itself and passes the socket descriptor to OpenSSL via SSL_set_fd.
We configured OpenSSL for multithread
support, setting up both the static and dynamic locking callbacks e.g.
CRYPTO_set_id_callback(), CRYPTO_set_locking_callback(), etc. For
the most part, the application functions well but we're seeing some anomalies.
To help us determine the cause, definitive answers to a few questions
The OpenSSL Frequently Asked Questions
page states that OpenSSL is thread safe, but maintains that a single "SSL
connection may not concurrently be used by multiple threads."
1a) True or False. OpenSSL connection
API calls (SSL_Read, SSL_Write, etc.) may execute concurrently on
the same SSL instance (pointer-to-SSL returned by a SSL_new call)?
1b) True or False. For blocking
sockets where SSL_MODE_AUTO_RETRY
is enabled, thread A can call SSL_Read() on SSL instance X while thread
B concurrently calls SSL_Write() on SSL instance X?
2) True or False. OpenSSL works
error free when an application uses non-blocking sockets and prevents concurrent
execution of SSL_Read and SSL_Write (as well as other connection API calls)
on the same SSL instance?
3a) True or False. OpenSSL
SSL instance's returned by SSL_new are bound to the single thread which
called SSL_new; bound meaning that the SSL instance may not be shared with
any other threads, the SSL instance is only valid for use on the thread
which called SSL_new?
3b) True or False. If thread
A i) calls SSL_new, obtaining an SSL instance X and ii) calls SSL_Read
using the SSL instance X. A failure will eventually occur if thread
B non-concurrently calls SSL_Read/SSL_Write using the same SSL instance