OPENSSL_init_ssl fails in RUN_ONCE and ossl_init_config

[MonkeybreadSoftware]

After upgrade to openssl 1.1.1 we got an issue that all the SSL stuff failed to work.

OPENSSL_init_ssl returned failure due to failure in OPENSSL_init_crypto before.
OPENSSL_init_crypto calls this block:

    if (opts & OPENSSL_INIT_LOAD_CONFIG) {
        int ret;
        CRYPTO_THREAD_write_lock(init_lock);
        appname = (settings == NULL) ? NULL : settings->appname;
        ret = RUN_ONCE(&config, ossl_init_config);
        CRYPTO_THREAD_unlock(init_lock);
        if (!ret)
            return 0;
    }

and that needs to be commented out of us to make it work again.
It looks like that with multiple invocations of OPENSSL_init_crypto in our code and used libraries, the second invocation fails and returns the error here. Not sure why, but now everything works again as it did with older OpenSSL version so far.

[MonkeybreadSoftware]

we call e.g.

int r1 = OPENSSL_init_crypto(OPENSSL_INIT_ADD_ALL_CIPHERS | OPENSSL_INIT_ADD_ALL_DIGESTS, NULL);
int r2 = OPENSSL_init_ssl(OPENSSL_INIT_LOAD_SSL_STRINGS | OPENSSL_INIT_LOAD_CRYPTO_STRINGS, NULL);

for our library to init.

[mattcaswell]

What platform are you running on?
Do you get any error message?
You say that the second invocation fails. Does that mean the first invocation succeeds?

[kaduk]

(As a workaround you should be able to just remove both the init calls from your code; 1.1.1 will auto-initialize itself. But that does not keep us from wanting to track down what's going on here.)

[MonkeybreadSoftware]

We use it on Mac, Windows and Linux. But I saw the problem both on Mac and Windows as we didn't test for Linux this time.

I can check in the next days for some details.

[MonkeybreadSoftware]

The problem is precisely that

ret = RUN_ONCE(&config, ossl_init_config);

returns 0, which than returns a failure from OPENSSL_init_crypto.
I see ossl_init_config always returns 1, so that may not be the problem.
But maybe some problem with RUN_ONCE returning zero?

Can you guys verify that OPENSSL_init_crypto works, if you call it several times with various parameters like OPENSSL_INIT_LOAD_CONFIG or OPENSSL_INIT_NO_LOAD_CONFIG?

[ejoerns]

We just fell across the same issue, when calling OPENSSL_init_crypto() (for using CMS functions) with OPENSSL_INIT_NO_LOAD_CONFIG followed by libcurl that calls OPENSSL_init_ssl() which itself calls OPENSSL_init_crypto() with OPENSSL_INIT_LOAD_CONFIG. This results in an error.

[michaelolbrich]

The problem is that ossl_init_config and ossl_init_no_config share the RUN_ONCE control argument. This means that if ossl_init_no_config was call once, then ossl_init_config will never be called.

The return value for RUN_ONCE is a static variable derived from the function name and initialized with '0'. In the failing case, this value is never changed, because the function is never called.

Several other option pairs have the same problem.

[richardweinberger]

I ran in into this issue too.
My legacy application used OPENSSL_no_config(), on 1.1.x SSL_CTX_new() started to return NULL because internally OPENSSL_init_ssl() was called and failed. :-(

[tmshort]

I am running into this issue. Because of this in OPENSSL_init_ssl():

    if (!OPENSSL_init_crypto(opts
#ifndef OPENSSL_NO_AUTOLOAD_CONFIG
                             | OPENSSL_INIT_LOAD_CONFIG
#endif
                             | OPENSSL_INIT_ADD_ALL_CIPHERS
                             | OPENSSL_INIT_ADD_ALL_DIGESTS,
                             settings))

Any attempt to use OPENSSL_INIT_NO_LOAD_CONFIG, OPENSSL_INIT_NO_ADD_ALL_CIPHERS or OPENSSL_INIT_NO_ADD_ALL_DIGESTS before creating an SSL_CTX with SSL_CTX_new() (if that's the first thing you typically do) will cause SSL_CTX_new() to fail, prevent all use of TLS. While the NO_ADD options are unlikely to be used, I do see the OPENSSL_INIT_NO_LOAD_CONFIG being used to prevent loading configuration.

[mattcaswell]

This should be fixed in git (commit f725fe5 for the 1.1.1 branch). Please try out the latest version in OpenSSL_1_1_1-stable and see if that solves the problem.

[tmshort]

Was this fixed by PR #7983 ?

[tmshort]

@mattcaswell just found that... but it's not in a tagged release, yet.

[mattcaswell]

Was this fixed by PR #7983 ?

Yes, one of the commits in that PR fixed a RUN_ONCE bug that causes this issue.

@mattcaswell just found that... but it's not in a tagged release, yet.

Correct this is git only so far. The fix will be in 1.1.1b

[tmshort]

Correct this is git only so far. The fix will be in 1.1.1b

Yeah, we deal with the tagged releases, so I'm not spending all my time rebasing our changes. ;) Any idea when 1.1.1b might come out? (It's been, what, almost 3 months since 1.1.1a?)

[mattcaswell]

We tend to do a release every 3-4 months (unless a security issue causes us to do one earlier) ....so "soon".

[tmshort]

Thought so... Thanks!

[xnox]

Given that 1.1.1b is out, should this issue be closed?

[MonkeybreadSoftware]

Well, I think for now you can close this.