This is a discussion on Clarification questions on OpenSSL thread-safe support - Openssl ; After studying the OpenSSL threads(3) man page: http://openssl.org/docs/crypto/threads.html and the FAQ: http://openssl.org/support/faq.html#PROG1 I'm still a bit confused about what's needed when using OpenSSL in a threaded environment. Most of the confusion results from the statements in the FAQ, and perhaps ...
After studying the OpenSSL threads(3) man page:
and the FAQ:
I'm still a bit confused about what's needed when using OpenSSL in a
threaded environment. Most of the confusion results from the statements
in the FAQ, and perhaps these questions can result in a clarification of
Is OpenSSL thread-safe?
Yes (with limitations: an SSL connection may not concurrently be
used by multiple threads). On Windows and many Unix systems,
OpenSSL automatically uses the multi-threaded versions of the
standard libraries. If your platform is not one of these,
consult the INSTALL file.
Multi-threaded applications must provide two callback functions
to OpenSSL by calling CRYPTO_set_locking_callback() and
CRYPTO_set_id_callback(). (For OpenSSL 0.9.9 or later, the new
function CRYPTO_set_idptr_callback() may be used in place of
CRYPTO_set_id_callback().) This is described in the threads(3)
1. What I understand from this is that OpenSSL can be thread safe.
In order for it to be safely used in multi-threaded
applications, it needs:
A. to be built with multi-threaded versions of the standard
B. to have the application provide the two callback
C. the application must avoid using the same SSL connection
by two different threads.
All of the above are necessary. In other words, it isn't
sufficient that OpenSSL was built with the multi-threaded
versions of the standard libraries. The application must also
set up the callbacks. (True or False, please?)
2. Related to question 1, the thread-safe requirements (A and B
above) are needed even if the different threads are not sharing
an SSL connection. (My understanding is that connections can't
ever be shared, and that the library still needs A and B in
order to be thread-safe.) (True or false?)
3. Instead of B (implementing the two callback functions), is it
sufficient for the application to provide it's own locking
around all SSL library calls? In other words, if the
application guarantees that only one thread will be in the
library at a time, is that sufficient?
4. I'm guessing from the semantics of CRYPTO_set_locking_callback()
and CRYPTO_set_id_callback(), that they are not to be called
more than once from an application. It seems like they have to
be called only at the beginning of the program, and not ever
again. (True or False?) Is there a way to know if they have
already been called later on?
5. There are some other "dynlock" functions described in the
threads(3) man page. The wording on that page implies that they
are only needed for performance, or maybe in a future version.
In my current application, they don't seem to be called. Is it
necessary to implement these? Will they only be for
performance? If I don't implement them, will my application
break in some future version of OpenSSL, or will it just run
slower? (The confusion results because the current man page has
wording: "Multi-threaded applications might crash at random if
it is not set", but also says "dynamic locks are currently not
used internally by OpenSSL, but may do so in the future" and
"some parts of OpenSSL need it for better performance".) What's
the real situation here?
6. Question 4 applies to the dynlock setup functions as well. Same
answer about calling them multiple times? Any user-callable API
to know whether they've already been called?
7. Not specifically concerning threads, but is it safe to call
SSL_library_init() more than once? (Does the library protect
against that, returning immediately if the initialization is
already done? Many libraries do this.) How about
Thanks for any help on these questions.
OpenSSL Project http://www.openssl.org
User Support Mailing List email@example.com
Automated List Manager firstname.lastname@example.org