PRNG not available when multiple providers are configured?

[Matt Caswell]

Ah! I had completely forgotten about this option.

Matt

On 03/11/2020 21:34, Dr Paul Dale wrote:
> 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 4 Nov 2020, at 4:41 am, Thomas Dwyer III <tomiii at tomiii.com
>> <mailto:tomiii at tomiii.com>> wrote:
>>
>> On Tue, Nov 3, 2020 at 7:13 AM Matt Caswell <matt at openssl.org
>> <mailto: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
>> <https://urldefense.com/v3/__https://www.openssl.org/docs/manmaster/man5/config.html__;!!GqivPVa7Brio!INBlyBEyGaYipDhT7pzBHbqNWwT_X9g1JEID9D5HZmFB-cmNRMWGUEoRqaZMNvs$> 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
>