Regarding thread safety of OpenSSL, we find the following statements in the official documentation:

The documentation on OpenSSL threads states (at least for version 1.0.2):

OpenSSL can safely be used in multi-threaded applications provided that at least two 
callback functions are set, locking_function and threadid_func.

The ChangeLog of version 1.1.0 states:

  *) OpenSSL now uses a new threading API. It is no longer necessary to
     set locking callbacks to use OpenSSL in a multi-threaded environment. There
     are two supported threading models: pthreads and windows threads. It is
     also possible to configure OpenSSL at compile time for "no-threads". The
     old threading API should no longer be used. The functions have been
     replaced with "no-op" compatibility macros.
     [Alessandro Ghedini, Matt Caswell]

Contradicting or hedging these statements, the following statements are made by OpenSSL core developers in #2147 :

• "the objects cannot be used concurrently in multiple threads"
• "any modification of openssl data structures is not safe"
• "OpenSSL has never supported concurrent use of its data objects."
• "the documentation is wrong, or misleading or incomplete"
• "The safety for use in multi-threaded applications means that there is not (unlocked) global state in the library that could be modified by concurrent calls from different threads, such as a global error queue or a static counter for the next free index into an array. "

Please correct and update the library documentation so that it is clear and accurately documented:

• what is regarded safe
• what is not regarded safe.

In particular, the following use case warrants attention (for example): Is it safe to create an SSL context, and then use the exact same context to negotiate concurrent connections in multiple threads?