8

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 would help.

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."

http://www.openssl.org/support/faq.html#PROG1

  1. 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)?
  2. 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?
  3. 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?
  4. 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?
  5. 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 X?
buzz3791
  • 1,683
  • 2
  • 20
  • 38
  • A memory leak anomaly we were encountering was due to failing to call ERR_remove_state(3) prior to thread termination as documented - https://www.openssl.org/docs/crypto/err.html – buzz3791 Sep 16 '14 at 14:40

2 Answers2

16

1.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)?

*False. No, you cannot use SSL_read / SSL_write concurrently on the same SSL instance.*

2.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?

*Same answer as above. With or Without SSL_MODE_AUTO_RETRY, you cannot use the same SSL instance X concurrently to do SSL_read and SSL_write parallelly*

3.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?

True. If no concurrent execution is there, then OpenSSL works fine for Blocking as well as Non-Blocking Sockets.

4.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?

False. The SSL instance is not bound to any thread by OpenSSL itself. You can use the SSL instance created in one thread in another thread as long as only one thread is using a single SSL instance at any one point of time.

5.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 X?

False. Both Thread A and Thread B can use the same SSL instance X, as long both don't do concurrent operations on SSL instance X.

Jay
  • 24,173
  • 25
  • 93
  • 141
0

Experimentally, if the SSL connection has passed the negociation stage, and there is no renegotiation afterwards, then the use of SSL_read and SSL_write concurrently proved to cause no harm. This is according to my tests where I integrated OpenSSL with Push Framework, a multi-threaded network library. However, everywhere we read, OpenSSL professionals insist that the same context can not be used by multiple threads in same time.

charfeddine.ahmed
  • 526
  • 2
  • 8
  • 16
  • 1
    "then the use of SSL_read and SSL_write concurrently proved to cause no harm" - If that's true, you simply got lucky somehow. You simply cannot have multiple threads doing IO operations on an instance of SSL*. It will corrupt, absolutely. This is precisely why the documentation on boost::asio::ssl demands that you wrap those operations in a strand. –  Apr 06 '15 at 10:28