You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Stefan Eissing <st...@greenbytes.de> on 2018/07/18 13:14:50 UTC
mod_ssl and openssl 1.0.2 initialization
Something fishy reported in https://bz.apache.org/bugzilla/show_bug.cgi?id=62552
Which points to a problem with CRYPTO_THREADID and crypto locks and initialization oder in OpenSSL 1.0.2. (I believe OpenSSL 1.1.x eleminated that).
During the analysis of the bug, there seem to be 3 modules in play that use openssl: mod_ssl, mod_md and mod_authn_dbd (mysql). Depending on configuration and load order the server works or crashes. Generally, the rule seems to be:
- without mod_authn_dbd (and directive for mysql driver), all is well
- with it, crash in mod_md md_crypto_init (which calls RAND_status(), which crashes)
- *unless* mod_ssl is loaded before the others.
This seems a bit nasty. Does someone of our mod_ssl experts agree to this analysis and that crypto locking is the issue?
If so, what can we do about it?
-Stefan
Re: mod_ssl and openssl 1.0.2 initialization
Posted by Stefan Eissing <st...@greenbytes.de>.
Well, if a auto-loaded core_ssl module publishes
an optional ap_ssl_crypto_init() function, mod_md
would sure like to call that.
Cheers, Stefan
> Am 23.07.2018 um 12:25 schrieb Yann Ylavic <yl...@gmail.com>:
>
> On Mon, Jul 23, 2018 at 12:05 PM, Plüm, Rüdiger, Vodafone Group
> <ru...@vodafone.com> wrote:
>>
>>> Von: Yann Ylavic <yl...@gmail.com>
>>>
>>> Yes, I agree that we have an issue with openssl (< 1.1)
>>> loading/unloading/initialization for different modules: core, mod_ssl,
>>> mod_md, mod_crypto (via APR), mod_authn_dbd (I wasn't aware of this
>>> one using openssl), ... (others?) may all use openssl and in arbitrary
>>> order depending on the configuration.
>>
>> You forgot mod_ldap depending on the LDAP library being used and how this
>> Library was compiled to support SSL.
>
> OK, if this can be determined at compile time we can always hook
> something (optional_fn_retrieve looks like a good candidate already).
>
>>>
>>> I wonder which module would provide them though, mod_ssl looks quite
>>> straightforward but then it would be a requirement for, e.g.
>>> mod_authn_dbd? This does not look right either...
>>> Or maybe there could be a way to autoload a mod_openssl (functional
>>> only) module?
>>
>> This looks like the most sane way. It could become very thin once something
>> in APR is available. Do we need to do the same for other crypto libraries, but
>> openssl or do they have a better design with this respect? If it is needed for them
>> as well, we should have one module that covers them all, not just openssl.
>
> apr_crypto_lib_init/term() exist for "nss" and "commoncrypto" already
> (plus two ENOTIMPLs for some MS implementations/stubs in APR crypto).
> We could steal code from there if needed.
>
>
> Regards,
> Yann.
Re: mod_ssl and openssl 1.0.2 initialization
Posted by Yann Ylavic <yl...@gmail.com>.
On Mon, Jul 23, 2018 at 12:05 PM, Plüm, Rüdiger, Vodafone Group
<ru...@vodafone.com> wrote:
>
>> Von: Yann Ylavic <yl...@gmail.com>
>>
>> Yes, I agree that we have an issue with openssl (< 1.1)
>> loading/unloading/initialization for different modules: core, mod_ssl,
>> mod_md, mod_crypto (via APR), mod_authn_dbd (I wasn't aware of this
>> one using openssl), ... (others?) may all use openssl and in arbitrary
>> order depending on the configuration.
>
> You forgot mod_ldap depending on the LDAP library being used and how this
> Library was compiled to support SSL.
OK, if this can be determined at compile time we can always hook
something (optional_fn_retrieve looks like a good candidate already).
>>
>> I wonder which module would provide them though, mod_ssl looks quite
>> straightforward but then it would be a requirement for, e.g.
>> mod_authn_dbd? This does not look right either...
>> Or maybe there could be a way to autoload a mod_openssl (functional
>> only) module?
>
> This looks like the most sane way. It could become very thin once something
> in APR is available. Do we need to do the same for other crypto libraries, but
> openssl or do they have a better design with this respect? If it is needed for them
> as well, we should have one module that covers them all, not just openssl.
apr_crypto_lib_init/term() exist for "nss" and "commoncrypto" already
(plus two ENOTIMPLs for some MS implementations/stubs in APR crypto).
We could steal code from there if needed.
Regards,
Yann.
AW: mod_ssl and openssl 1.0.2 initialization
Posted by Plüm,
Rüdiger,
Vodafone Group <ru...@vodafone.com>.
> -----Ursprüngliche Nachricht-----
> Von: Yann Ylavic <yl...@gmail.com>
> Gesendet: Montag, 23. Juli 2018 11:50
> An: httpd-dev <de...@httpd.apache.org>
> Betreff: Re: mod_ssl and openssl 1.0.2 initialization
>
> On Wed, Jul 18, 2018 at 3:14 PM, Stefan Eissing
> <st...@greenbytes.de> wrote:
> > Something fishy reported in
> > https://bz.apache.org/bugzilla/show_bug.cgi?id=62552
> >
> > Which points to a problem with CRYPTO_THREADID and crypto locks and
> > initialization oder in OpenSSL 1.0.2. (I believe OpenSSL 1.1.x
> > eleminated that).
> >
> > During the analysis of the bug, there seem to be 3 modules in play
> > that use openssl: mod_ssl, mod_md and mod_authn_dbd (mysql).
> > Depending on configuration and load order the server works or
> > crashes.
>
> Yes, I agree that we have an issue with openssl (< 1.1)
> loading/unloading/initialization for different modules: core, mod_ssl,
> mod_md, mod_crypto (via APR), mod_authn_dbd (I wasn't aware of this
> one using openssl), ... (others?) may all use openssl and in arbitrary
> order depending on the configuration.
You forgot mod_ldap depending on the LDAP library being used and how this
Library was compiled to support SSL.
>
>
> > Generally, the rule seems to be:
> >
> > - without mod_authn_dbd (and directive for mysql driver), all is
> > well - with it, crash in mod_md md_crypto_init (which calls
> > RAND_status(), which crashes) - *unless* mod_ssl is loaded before the
> > others.
> >
> > This seems a bit nasty. Does someone of our mod_ssl experts agree to
> > this analysis and that crypto locking is the issue?
> >
> > If so, what can we do about it?
>
> I started to try to centralize openssl setup in APR (r1833421, but I'm
> being cautious here because it kind of has been reverted lately...).
> What do you think of an 'apr_crypto_lib_init("openssl", ..., pool)'
> call from any module, where all the init/cleanup would be done once
> for all with the lifetime of the given pool (pconf, or pglobal if the
> core itself uses openssl).
> It does not include threads' locking for now, but this could be added
> based on existing httpd code.
>
> Unfortunately in any case this will require APR-1.7 (at best), so in
> the meantime we might want an httpd only solution, like optional
> functions.
> I wonder which module would provide them though, mod_ssl looks quite
> straightforward but then it would be a requirement for, e.g.
> mod_authn_dbd? This does not look right either...
> Or maybe there could be a way to autoload a mod_openssl (functional
> only) module?
This looks like the most sane way. It could become very thin once something
in APR is available. Do we need to do the same for other crypto libraries, but
openssl or do they have a better design with this respect? If it is needed for them
as well, we should have one module that covers them all, not just openssl.
Regards
Rüdiger
Re: mod_ssl and openssl 1.0.2 initialization
Posted by Yann Ylavic <yl...@gmail.com>.
On Mon, Jul 23, 2018 at 11:50 AM, Yann Ylavic <yl...@gmail.com> wrote:
>
> I started to try to centralize openssl setup in APR (r1833421, but I'm
> being cautious here because it kind of has been reverted lately...).
> What do you think of an 'apr_crypto_lib_init("openssl", ..., pool)'
> call from any module, where all the init/cleanup would be done once
> for all with the lifetime of the given pool (pconf, or pglobal if the
> core itself uses openssl).
Btw, this is already used in trunk's ssl_hook_pre_config(), it takes
into account the case where ap_init_rng() already initialized openssl
on pglobal (so in mod_ssl apr_crypto_lib_init("openssl") can be a
noop), but this could work between modules too (with pconf).
Re: mod_ssl and openssl 1.0.2 initialization
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Jul 18, 2018 at 3:14 PM, Stefan Eissing
<st...@greenbytes.de> wrote:
> Something fishy reported in
> https://bz.apache.org/bugzilla/show_bug.cgi?id=62552
>
> Which points to a problem with CRYPTO_THREADID and crypto locks and
> initialization oder in OpenSSL 1.0.2. (I believe OpenSSL 1.1.x
> eleminated that).
>
> During the analysis of the bug, there seem to be 3 modules in play
> that use openssl: mod_ssl, mod_md and mod_authn_dbd (mysql).
> Depending on configuration and load order the server works or
> crashes.
Yes, I agree that we have an issue with openssl (< 1.1)
loading/unloading/initialization for different modules: core, mod_ssl,
mod_md, mod_crypto (via APR), mod_authn_dbd (I wasn't aware of this
one using openssl), ... (others?) may all use openssl and in arbitrary
order depending on the configuration.
> Generally, the rule seems to be:
>
> - without mod_authn_dbd (and directive for mysql driver), all is
> well - with it, crash in mod_md md_crypto_init (which calls
> RAND_status(), which crashes) - *unless* mod_ssl is loaded before the
> others.
>
> This seems a bit nasty. Does someone of our mod_ssl experts agree to
> this analysis and that crypto locking is the issue?
>
> If so, what can we do about it?
I started to try to centralize openssl setup in APR (r1833421, but I'm
being cautious here because it kind of has been reverted lately...).
What do you think of an 'apr_crypto_lib_init("openssl", ..., pool)'
call from any module, where all the init/cleanup would be done once
for all with the lifetime of the given pool (pconf, or pglobal if the
core itself uses openssl).
It does not include threads' locking for now, but this could be added
based on existing httpd code.
Unfortunately in any case this will require APR-1.7 (at best), so in
the meantime we might want an httpd only solution, like optional
functions.
I wonder which module would provide them though, mod_ssl looks quite
straightforward but then it would be a requirement for, e.g.
mod_authn_dbd? This does not look right either...
Or maybe there could be a way to autoload a mod_openssl (functional
only) module?