PRNG not available when multiple providers are configured?

[Thomas Dwyer III]

On Tue, Nov 3, 2020 at 7:13 AM Matt Caswell <matt at openssl.org> wrote:

>
>
> On 03/11/2020 00:55, Thomas Dwyer III wrote:
> > I'm having trouble getting RAND_status() to return 1 when my openssl.cnf
> > has both the default provider and the fips provider configured at the
> > same time:
> >
> >         openssl_conf = openssl_init
> >
> >         [openssl_init]
> >         providers = provider_sect
> >
> >         [provider_sect]
> >         default = default_sect
> >         fips = fips_sect
> >
> >         [default_sect]
> >         activate = 1
> >
> >         .include /conf/openssl/fips.cnf
> >
> > If I remove either default or fips from [provider_sect] then
> > RAND_status() returns 1. If I leave them both specified there,
> > RAND_status() always returns 0. Is this the expected behavior or am I
> > doing something wrong? I understand that I must specify properties when
> > fetching algorithms in order to get deterministic behavior with multiple
> > providers loaded. Is there an analogous API for the PRNG that I'm
> > overlooking?
> >
> > Interestingly, setting activate=0 for either provider is not sufficient
> > to work around this issue.
>
> I tested this out and was able to replicate your behaviour.
>
> The reasons are a little complicated (see below) but the TL;DR summary
> is that there is an error in your config file. The ".include" line
> should specify a config file relative to OPENSSLDIR (or
> OPENSSL_CONF_INCLUDE if it is set). It cannot be an absolute path, and
> hence fips.cnf is not being found.
>


This explanation does not match my observations. strace clearly shows my
fips.cnf getting opened and read when my openssl.cnf has an absolute path.
Likewise, strace shows stat64("fips.cnf", ...) failing (and thus no
subsequent open() call) when I use a relative path. Furthermore, the
documentation at https://www.openssl.org/docs/manmaster/man5/config.html
says this should be an absolute path.

That said, see below..



> I've seen this error a few times now so I'm thinking that we should
> perhaps allow absolute paths. I'm not sure what the reason for
> disallowing them was.
>
> The reason it works if you comment out the "default" line is because
> that means the only provider left is the FIPS one. But the config line
> for that is faulty and therefore activating it fails. Ultimately we have
> not succesfully activated any provider. When you call RAND_status() it
> will attempt to fetch the RAND implementation and find that no providers
> have been activated. In this case we fallback and automatically activate
> the default provider. Hence you end up with RAND_status() still working.
>
> If you comment out the "fips" line then it works because it doesn't
> attempt to do anything with the fips provider, successfully activates
> the default provider, and hence RAND_status() works as expected.
>
> If you have both lines in the config file then it first successfully
> activates the default provider. It next attempts to activate the fips
> provider and fails. The way the config code works is that if any of the
> configured providers fail to activate then it backs out and deactivates
> all of them. At this point we're in a situation where a provider has
> been successfully activated and then deactivated again. The fallback
> activation of the default provider only kicks in if you've not attempted
> to activate any providers by the time you first need one. Therefore the
> default provider doesn't activate as a fallback either. Ultimately you
> end up with no active providers and RAND_status() fails.
>

Ah ha! This explanation makes sense to me and indeed pointed me at the real
problem. I had recompiled OpenSSL but I forgot to update the hmac in
fips.cnf via fipsinstall. So yes, the fips provider was failing to activate
because of that. As soon I fixed the hmac RAND_status() started working for
me. So THANKS for that! :-)


Tom.III




> We really should have a way of getting more verbose output in the event
> of config issues like this.
>
> Matt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20201103/57dcb87e/attachment.html>