1

The OpenSSL FAQ states that it can be used in threaded applications:

1. Is OpenSSL thread-safe?

Provided an application sets up the thread callback functions, the answer is yes.

This callback functions refers to a global SSL-lock, thus if you have 2 ssl connections running these will both use this global lock.

However the FAQ continues:

There are limitations; for example, an SSL connection cannot be used concurrently by multiple threads. This is true for most OpenSSL objects.

This indicates that an additional mutex is needed for every SSL-connection. Is this correct? Or do I not need the additional mutex for every SSL-connection?

Community
  • 1
  • 1
sigvardsen
  • 1,531
  • 3
  • 26
  • 44
  • Possible duplicate of [Using OpenSSL in a multi-threaded application](http://stackoverflow.com/q/11251859) and [SSL read and SSL write simultaneously](http://stackoverflow.com/q/21527206). – jww Feb 25 '16 at 12:50

1 Answers1

4

It means that if your connection is shared by multiple threads, you need to have a mutex to avoid them all manipulating the connection at the same time.

As long as any single connection is only used by one thread at a time (which in most applications is the normal case), you don't need any further locking.

Joachim Isaksson
  • 176,943
  • 25
  • 281
  • 294
  • I know, but do I also need the global mutex, when using multiple connections? I.e using `CRYPTO_set_locking_callback()`? – sigvardsen Feb 24 '16 at 19:59
  • Ok, sorry for being dense here, but are we talking multiple connections, multiple threads or both in combination? – Joachim Isaksson Feb 24 '16 at 20:23
  • Sorry for not being clear, but we are talking multiple connections with multiple threads. – sigvardsen Feb 24 '16 at 20:24
  • 2
    For multiple threads using the library at all, you _always_ need to set the locking callback and the threadid callback. See for example [here](https://curl.haxx.se/libcurl/c/opensslthreadlock.html) for a very simple implementation of both. _As long as you don't share objects fetched from OpenSSL (such as a connection) between threads, that's all you need_, but if you need to share a single connection object between threads, you need to make sure yourself that no two threads access the connection at the same time. – Joachim Isaksson Feb 24 '16 at 20:31
  • Isaaksson Thank you! – sigvardsen Feb 24 '16 at 20:34
  • OpenSSL connections are like most things provided by libraries -- you can't try to modify their state from two threads at the same time. This is important to point out because people typically expect OpenSSL connections to behave like TCP connections. TCP connections, like most things provided by kernels, are inherently thread safe for most rational combinations of operations. – David Schwartz Feb 24 '16 at 22:53