OpenSSL 3.0 FIPS questions

Tue Oct 26 21:15:10 UTC 2021

Actually, if you are running on the same machine that you built OpenSSL, you are fine. I cross-compile and have to do a fipsinstall each time. My apologies.

> On Oct 26, 2021, at 12:17 PM, Jason Schultz <jetson23 at hotmail.com> wrote:
> 
> Thanks for all of the help so far. Unfortunately, I'm still struggling with this. There could be a number of issues, starting with the installation of OpenSSL. I basically followed the documentation and did the following:
> 
> ./Configure enable-fips
> make
> make test
> make install
> 
> The "make test" actually fails, but I did not troubleshoot as it seems like a lot of systems have issues here. But I know the .so produced when I build my application is linking to the correct OpenSSL libraries (libssl.so.3 and libcrypto.so.3). Checking the OpenSSL version shows 3.0.
> 
> I've tried a number of combinations trying to make this work, starting with the code from Dr. Paul Dale in a previous message:
> 
>     fips_libctx = OSSL_LIB_CTX_new();
>     if (!fips_libctx)
>         // error handling
> 
>     non_fips_libctx = OSSL_LIB_CTX_new();
>     if (!non_fips_libctx)
>         // error handling
> 
>     fipsp = OSSL_PROVIDER_load(fips_libctx, "fips");
>     if (fipsp == NULL)
>       {
>         /* error handling */
>       }
> 
>     
>     basep = OSSL_PROVIDER_load(fips_libctx, "base"); 
>     if (basep == NULL)
>       {
>         /* error handling */
>       }
> 
>     defp = OSSL_PROVIDER_load(non_fips_libctx, "default");
>     if (defp == NULL)
>       {
>         /* error handling */
>       }
> 
>     /* Disallow falling back to the default library context */
>     
>     nullp = OSSL_PROVIDER_load(NULL, "null");
>     if (nullp == NULL)
>       {
>         /*error handling */
>       }
> 
> With the code like the above, the OSSL_PROVIDER_load() calls fails for fips. If I try to use the fips_libctx in SSL_CTX_new_ex(), it fails and returns NULL, which is probably expected given the fips provider didn't load.
> 
> At that point, I wasn't sure if my application was using the (correct) config file in /usr/local/ssl/. I don't have any environment variables set up, and would prefer not to have to set any to get this to work. So I changed the provider load for FIPS to use OSSL_LIB_CTX_load_config():
> 
>     if (!OSSL_LIB_CTX_load_config(fips_libctx, "/usr/local/ssl/openssl-fips.cnf"))
>           // error handling
> 
> This seems to work load the provider; however, there are two separate problems at this point. If FIPS is enabled by my application creating the SSL_CTX with  the FIPS library context fails, returning NULL. 
> 
> If FIPS is turned OFF by my application, creating an SSL_CTX with the non_fips_libctx  is successful, but later calling X509_get_pubkey() returns NULL, implying maybe something is wrong with the non_fips_libctx as well. 
> 
> I've tried other combinations, but at this point I'm just guessing. Is there anything obvious I could be missing and I should be checking?
> 
> Thanks,
> 
> Jason
> 
> 
> From: Dr Paul Dale <pauli at openssl.org>
> Sent: Monday, October 25, 2021 9:37 PM
> To: Jason Schultz <jetson23 at hotmail.com>; openssl-users at openssl.org <openssl-users at openssl.org>
> Subject: Re: OpenSSL 3.0 FIPS questions
>  
> It was meant for the second method only.  The first method is using different library contexts to distinguish FIPS algorithms.  Using the properties in addition is harmless and might prevent a future mistake that breaks compliance.
> 
> Pauli
> 
> On 26/10/21 4:46 am, Jason Schultz wrote:
>> Thanks again. I think most of that makes sense. Going back to your initial response, there is something I'm not clear on. 
>> 
>> The second method you explained (which I don't plan to use) starting with "Alternatively,..." included the calls to OSSL_PRIVIDER_load(), and then discussed calling the following API for FIPS:
>>    EVP_set_default_properties(NULL, “fips=yes”);
>> 
>> Was the EVP_set_default_properties() call specifically and only for the 2nd method, or did that API call apply to both the first and second methods you explained? From reading the doc for that call, it seems like I should be doing it if I use the first method as well.
>> 
>> Regards,
>> 
>> Jason
>> 
>> From: openssl-users <openssl-users-bounces at openssl.org> <mailto:openssl-users-bounces at openssl.org> on behalf of Dr Paul Dale <pauli at openssl.org> <mailto:pauli at openssl.org>
>> Sent: Sunday, October 24, 2021 11:12 PM
>> To: openssl-users at openssl.org <mailto:openssl-users at openssl.org> <openssl-users at openssl.org> <mailto:openssl-users at openssl.org>
>> Subject: Re: OpenSSL 3.0 FIPS questions
>>  
>> The configuration shouldn't have much impact.  You will need a fips section specifying where the integrity check data are.  You shouldn't need base or default sections.
>> 
>> 
>> Pauli
>> 
>> On 25/10/21 5:23 am, Jason Schultz wrote:
>>> Thank you for your response. I think all of that makes sense, and seems to accomplish what I want programmatically, limiting it to my application. I guess the only question I have is what about the config files? Should they remain as they were installed, or do I need to provide sections for fips, base, default, etc?
>>> 
>>> Regards,
>>> 
>>> Jason
>>> 
>>> 
>>> From: openssl-users <openssl-users-bounces at openssl.org> <mailto:openssl-users-bounces at openssl.org> on behalf of Dr Paul Dale <pauli at openssl.org> <mailto:pauli at openssl.org>
>>> Sent: Sunday, October 24, 2021 12:28 AM
>>> To: openssl-users at openssl.org <mailto:openssl-users at openssl.org> <openssl-users at openssl.org> <mailto:openssl-users at openssl.org>
>>> Subject: Re: OpenSSL 3.0 FIPS questions
>>>  
>>> Oops, the second time this occurs "defp = OSSL_PROVIDER_load(non_fips_libctx, "default");" it should be "defp = OSSL_PROVIDER_load(NULL, "default");"
>>> 
>>> 
>>> Pauli
>>> 
>>> On 24/10/21 10:06 am, Dr Paul Dale wrote:
>>>> defp = OSSL_PROVIDER_load(non_fips_libctx, "default");

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20211026/d254c42b/attachment.html>