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 these questions can result in a clarification of this section: 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) manpage. My questions: 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 libraries, B. to have the application provide the two callback functions, and 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 SSL_load_error_strings()? ERR_load_BIO_strings()? Thanks for any help on these questions. Bryan Sutula ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
