| Adding: config_diagnostics = 1
At the same level as the openssl_conf line should produce more output. Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
On Tue, Nov 3, 2020 at 7:13 AM Matt Caswell < matt@xxxxxxxxxxx> 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
|
