OpenSSL 3.0 FIPS questions

Thu Oct 28 18:03:20 UTC 2021

On 28/10/2021 18:33, Jason Schultz wrote:
> Thanks Matt. I think I have what I need as far as loading providers. I 
> also did the test you suggested with EVP_MD_fetch() and things failed as 
> expected, the fetch did not work.
> 
> One other question on providers, given how I load everything, it seems 
> like before application exit, the cleanup should be the following:
> 
>      OSSL_LIB_CTX_free(fips_libctx);
>      OSSL_LIB_CTX_free(non_fips_libctx);
>      OSSL_PROVIDER_unload(defp);

Yes, but I would recommend unloading the default provider before freeing 
the libctx it is associated with. Otherwise bad things might happen.

> 
> Since I didn't "explicitly" load the fips and base providers with API 
> calls, I only need to unlead the default provider, as well as free both 
> library contexts.

Correct.

> 
> Also, when I did try to unload the fips and base providers, the call to 
> OSSL_PROVIDER_unload() hung, with the following backtrace:

Yeah. Don't do that. :-)

Matt

> 
> #1  0x00007fb37f51d709 in CRYPTO_THREAD_read_lock () from 
> /lib64/libcrypto.so.3
> #2  0x00007fb37f50c068 in ossl_lib_ctx_get_data () from 
> /lib64/libcrypto.so.3
> #3  0x00007fb37f519482 in get_provider_store () from /lib64/libcrypto.so.3
> #4  0x00007fb37f519af9 in provider_deactivate () from /lib64/libcrypto.so.3
> #5  0x00007fb37f51b813 in ossl_provider_deactivate () from 
> /lib64/libcrypto.so.3
> #6  0x00007fb37f518399 in OSSL_PROVIDER_unload () from /lib64/libcrypto.so.3
> 
> Thanks,
> 
> Jason
> 
> 
> ------------------------------------------------------------------------
> *From:* Matt Caswell <matt at openssl.org>
> *Sent:* Thursday, October 28, 2021 2:00 PM
> *To:* Jason Schultz <jetson23 at hotmail.com>; Dr Paul Dale 
> <pauli at openssl.org>; openssl-users at openssl.org <openssl-users at openssl.org>
> *Subject:* Re: OpenSSL 3.0 FIPS questions
> 
> 
> On 28/10/2021 14:49, Jason Schultz wrote:
>> A call to OSSL_PROVIDER_available() says the "default" provider is 
>> available;  however, I'm wondering if I should be loading the default 
>> provider via *load_config() as well? I would have to uncomment the 
>> "activate = 1" in the default section of my config though.
> 
> This is entirely a matter of personal taste. It makes no difference
> functionally whether you load a provider via OSSL_PROVIDER_load()
> directly, or whether you do it via the config file. Obviously if you do
> it via a config file it gives you the ability to modify what providers
> get loaded later without having to recompile.
> 
> If you decided to do it via config then you probably want *2* different
> config files. One for the fips libctx and one for the non-fips libctx.
> 
> 
>> 
>> I also still have this in my code:
>> 
>>      /* Disallow falling back to the default library context */
>>      nullp = OSSL_PROVIDER_load(NULL, "null");
>> 
>> But not sure it's having any affect?
> 
> You could attempt to test it by attempting to fetch an algorithm. We
> would expect it to fail if it is working as expected. E.g.
> 
> EVP_MD *md = EVP_MD_fetch(NULL, "SHA2-256", NULL);
> if (md != NULL) {
>       /* Should not happen! The null provider should prevent this */
> }
> 
> 
>> 
>> I do know that later in my application, both in "FIPS" or "non-FIPS" 
>> mode, I can  create an SSL_CTX with SSL_CTX_new_ex(). I also 
>> successfully call several APIs using both the fips_libctx or the 
>> non_fips_libctx, for example:
>> 
>> status = SSL_CTX_use_PrivateKey_file(ctx,<file>,SSL_FILETYPE_PEM);
>> 
>> status = SSL_CTX_use_certificate_file(ctx,<file>,SSL_FILETYPE_PEM);
>> 
>> status = SSL_CTX_check_private_key(ctx);
>> 
>> 
>> All return successfully. So I think what I have between configuration 
>> files and API calls accomplishes what I need to. Would anyone reading 
>> this agree?
> 
> It sounds correct from what you have described.
> 
> Matt
> 
>> 
>> I'm running into another issue that I need to troubleshoot a bit more 
>> before I add too much information and too many questions to a single 
>> message.
>> 
>> Thanks to everyone for their help with this, things are starting to make 
>> more sense now.
>> 
>> 
>> 
>> ------------------------------------------------------------------------
>> *From:* Matt Caswell <matt at openssl.org>
>> *Sent:* Thursday, October 28, 2021 7:39 AM
>> *To:* Jason Schultz <jetson23 at hotmail.com>; Dr Paul Dale 
>> <pauli at openssl.org>; openssl-users at openssl.org <openssl-users at openssl.org>
>> *Subject:* Re: OpenSSL 3.0 FIPS questions
>> 
>> 
>> On 27/10/2021 17:28, Jason Schultz wrote:
>>> With these config files and the code above, the 
>>> OSSL_PROVIDER_load(fips_libctx, "fips") call fails. Here are the 
>>> messages from the ERR_print_errors_fp() call:
>>> 
>>> 2097C692B57F0000:error:1C8000D5:Provider routines:(unknown 
>>> function):missing config data:providers/fips/self_test.c:289:
>>> 2097C692B57F0000:error:1C8000E0:Provider routines:(unknown 
>>> function):fips module entering error state:providers/fips/self_test.c:387:
>>> 2097C692B57F0000:error:1C8000D8:Provider routines:(unknown 
>>> function):self test post failure:providers/fips/fipsprov.c:706:
>>> 2097C692B57F0000:error:078C0105:common libcrypto routines:(unknown 
>>> function):init fail:crypto/provider_core.c:903:name=fips
>> 
>> 
>> This tells us that the fips provider has successfully loaded, but then
>> subsequently failed during its self-test because it cannot find its
>> config data.
>> 
>> I can see that you have created a separate libctx for fips. However
>> automatic loading of the config file only works for the *default*
>> libctx. If you create your own one then you need to explicitly load the
>> config file:
>> 
>> if (!OSSL_LIB_CTX_load_config(fips_libtx, "/usr/local/ssl/openssl.cnf")) {
>>       /* error handling */
>> }
>> 
>> Actually if you do this then you should not need to call
>> OSSL_PROVIDER_load() explicitly to load the fips provider since you
>> already activated it in the config file. You can either drop the
>> explicit call to OSSL_PROVIDER_load() for the fips provider, or remove
>> the "activate = 1" line in "fips_sect" in fipsmodule.cnf. This is just a
>> minor optimisation though. Doing both is redundant but harmless. You
>> could also load the base provider via config if you wanted to.
>> 
>> Matt
>> 
>> 