Guidance on proper usage of OpenSSL_add_all_digests

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Guidance on proper usage of OpenSSL_add_all_digests

Neptune
This post was updated on .
Using OpenSSL 1.0.1l

I just learned the painful way that OpenSSL_add_all_digests() is not a thread-safe function. I had been calling this in the constructor of a class providing hash functions for multiple threads. My question is, how do I know if a thread instantiating my class has called OpenSSL_add_all_digests() or not? Is there a way to query OpenSSL for the state of the table?

Google searches bring back about a dozen different "proper" ways of initializing, so I am asking for some expert guidance.

Thanks!
Reply | Threaded
Open this post in threaded view
|

Re: Guidance on proper usage of OpenSSL_add_all_digests

Jeffrey Walton-3
On Wed, Mar 2, 2016 at 12:27 PM, Neptune <[hidden email]> wrote:

> Using OpenSSL 1.0.1l
>
> I just learned the painful way that OpenSSL_add_all_digests() is not a
> thread-safe function. I had been calling this in the constructor of a class
> providing hash functions for multiple threads. My question is, how do I know
> if a thread instantiating my class has called OpenSSL_add_all_digests() or
> not? Is there a way to query OpenSSL for the state of the table? Perhaps
> more importantly, is it a requirement to call this function at all? My test
> application seems quite happy to do SHA1 hashes without calling any of the
> *add_all* functions :-/
>

Generally you want to provide initialization on the primary thread
during program startup. That's when you do things like installing the
locks, too. OpenSSL 1.1.0 adds OPENSSL_init_ssl, but its not clear to
me if it allows you to query subsystem initialization.

You can perform initialization in a static C++ ctor, but it can be
tricky because the C++ committee has never addressed the problem of
initialization order across translation units. Also see What's the
"static initialization order fiasco"?
(http://www.parashift.com/c++-faq/static-init-order.html).

Because of gaps in the C++ language, I usually do it in a c++ class
ctor, but the object resides in main(). On the occasions that the C++
class is instantiated as a static object, I use two techniques to
ensure the order of initialization. The first is object file ordering.
The second is compiler attributes, like "__attribute__ ((init_priority
(250)))" (with Clang/GCC/ICC) and "#pragma init_seg({user | lib})"
(with MSVC).

Unfortunately, there is no reasonable way to audit c++ static
constructor order for quality assurance purposes. Also see How to
verify init_priorty for C++ static object initialization order?
(http://sourceware.org/ml/binutils/2015-09/msg00173.html) on the
Binutils mailing list.

Regardless of how you do it, this is what you want to do:
https://wiki.openssl.org/index.php/Library_Initialization. The short
of this is call the following two functions:

  * SSL_library_init()
  * SSL_load_error_strings()

Finally, for the crypto components, like SHA... I don't believe they
need explicit initialization unless you are doing something like
changing the default implementation from software to an engine. The
SSL part of the library allows you to explicitly add selected
algorithms to control what algorithms are used in that portion of the
library.

Jeff
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Guidance on proper usage of OpenSSL_add_all_digests

Jeffrey Walton-3
> Finally, for the crypto components, like SHA... I don't believe they
> need explicit initialization unless you are doing something like
> changing the default implementation from software to an engine. The
> SSL part of the library allows you to explicitly add selected
> algorithms to control what algorithms are used in that portion of the
> library.

My bad.. "Library Initialization | libcrypto Initialization"
(http://wiki.openssl.org/index.php/Library_Initialization#libcrypto_Initialization)
sates you can use either OpenSSL_add_all_ciphers,
OPENSSL_add_all_algorithms_noconf, or you can pick what you want when
initializing crypto portion of the library.

For picking what you want:

    void MyLIB_init_crypto(void)
    {
        EVP_add_cipher(EVP_sha1());
    }

The earlier still holds true. Initialize and install lock on the
primary thread. And take care when using static C++ objects.

Jeff
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Guidance on proper usage of OpenSSL_add_all_digests

Tom Francis-2
In reply to this post by Neptune

> On Mar 2, 2016, at 12:27 PM, Neptune <[hidden email]> wrote:
>
> Using OpenSSL 1.0.1l
>
> I just learned the painful way that OpenSSL_add_all_digests() is not a
> thread-safe function. I had been calling this in the constructor of a class
> providing hash functions for multiple threads. My question is, how do I know
> if a thread instantiating my class has called OpenSSL_add_all_digests() or
> not? Is there a way to query OpenSSL for the state of the table? Perhaps
> more importantly, is it a requirement to call this function at all? My test
> application seems quite happy to do SHA1 hashes without calling any of the
> *add_all* functions :-/

You should initialize OpenSSL prior to starting any threads.  Likewise, you should then de-initialize it only after all threads (except your main thread, of course) have finished.  If you absolutely have to do it inside some secondary thread, then initialize a value to tell you if you’ve initialized OpenSSL or not and look at it.  If you’re using pthreads, you could put your OpenSSL initialization in a single function, and then in each thread, invoke it with pthread_once().  That way it’ll never be called more than once.  That still leaves you with the issue of cleanup, but that might not matter, depending on how you use it.

This is changing with OpenSSL 1.1, but for the better.  IIUC, most users won’t need to bother with initialization at all.


> Google searches bring back about a dozen different "proper" ways of
> initializing, so I am asking for some expert guidance.

A lot of the differences come down to personal preference.  You don’t have to call OpenSSL_add_all_digests(), depending on what you’re doing, but I’d recommend either calling it, or calling EVP_add_digest() for each digest you intend to use.  I’d also suggest that if it’s working without either call, then perhaps you’re not doing it right. :)  Avoid using any functions like SHA1_Init(); use EVP_DigestInit(), instead.  The EVP interfaces are superior, especially when you eventually need to change which hashing algorithm to use.

TOM

> Thanks!
>
>
>
> --
> View this message in context: http://openssl.6102.n7.nabble.com/Guidance-on-proper-usage-of-OpenSSL-add-all-digests-tp64243.html
> Sent from the OpenSSL - User mailing list archive at Nabble.com.
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Guidance on proper usage of OpenSSL_add_all_digests

Chris Gray-4
In reply to this post by Jeffrey Walton-3
> On Wed, Mar 2, 2016 at 12:27 PM, Neptune <[hidden email]> wrote:
> [...]
> You can perform initialization in a static C++ ctor, but it can be
> tricky because the C++ committee has never addressed the problem of
> initialization order across translation units. Also see What's the
> "static initialization order fiasco"?
> (http://www.parashift.com/c++-faq/static-init-order.html).

So static initialisation in Java is not the most capricious and
error-prone mechanism ever invented?  My faith in mankind takes yet
another knock.


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users