Is standard OpenSSL provider strictly necessary for FIPS support?

[lordgamez]

Hi,

My application is using AWS SDK CPP built from source, linked statically to my application, and through the submodules of the project s2n-tls is also built and statically linked to the AWS extension in the project. The application is using the OpenSSL library and I'm in the process of adding FIPS support, so I was happy to see that s2n-tls also added FIPS support using OpenSSL in the latest release. In the documentation it was stated that "s2n-tls requires that Openssl be configured with the standard provider in addition to the FIPS provider". I have some questions regarding this:

• In the OpenSSL provider list I could not find the "standard" provider, does this refer to the "default" provider or is this something separate?
• In my application if FIPS mode is set up, then only the base provider and the fips provider are activated, and while I was testing with the latest s2n-tsl library it seemed to be working without a problem. In my use cases I was only using S3 operations like upload, fetch, list and delete. Is it possible that in my use case the base provider should be enough? Is there any more information about that in which cases the base provider could not be sufficient?

Thank you in advance!

[lrstewart]

You're right, "standard" is absolutely a mistake and I definitely meant "default". PR to correct: #5214

For the base provider being sufficient, I would expect even just s2n_connection_new to fail without the default provider. You can see where we retrieve non-FIPS algorithms in our codebase from this search. In one of those places, we setup an MD5 hash when creating a connection. The other uses of the default provider (signing and pre-TLS1.2 secret derivation) can be avoided if only TLS1.3 is supported, but that s2n_connection_new currently can't.

Is the default provider not an acceptable requirement? s2n-tls can theoretically operate with just the base provider, but it would require some refactors around version negotiation and substantial cleanup of our tests.

[lordgamez]

Hi @lrstewart, thanks for the correction and the clarification!

I was only wondering that why was the AWS SDK still working in our use case only with the fips and base provider loaded. Is it possible that the AWS SDK is not using any of the non-fips compliant algorithms of S2N or they are failing silently in our S3 use cases?

The reason I did not want to load the default provider is to make sure that no non-fips compliant algorithms are used in the application and make it easier to find any fips-compliancy breaking issues in the future. But after seeing your examples I think it should not be a problem. As you pointed out even if the default provider is loaded the non-fips compliant algorithms need to explicitly define a context without fips to be used when FIPS properties are set in the default context. As I understand not fips-compliant algorithms can still be used if the they are only used for a generic checksum calculation without any cryptographic needs and still comply with the FIPS standard. If you can confirm this I will keep the default provider loaded in the application.

[lrstewart]

I'm actually worried something is wrong with your configuration or linking, because I'd expect it to fail very loudly no matter what algorithms / security policy you're using. If I switch from default to base in my local test build, I see failures from s2n_connection_new. Can you try calling the s2n_get_fips_mode method in your application to confirm that s2n-tls is actually in FIPS mode: https://github.com/aws/s2n-tls/blob/main/api/s2n.h#L246-L265

If you can confirm this I will keep the default provider loaded in the application.

I can't comment on compliance with the FIPS standard-- you should consult with an accredited CMVP lab or a compliance specialist on that topic. But s2n-tls will negotiate any options supported by the libcrypto and included in the security policy, regardless of whether it is operating in FIPS mode or not. The security policy determines what cipher suites, signature algorithms, etc are allowed.

[lordgamez]

Thanks for the tip, I checked what is happening a bit deeper and it seems to be in FIPS mode, but the s2n library doesn't seem to be used by the application. When I checked the call stack with the debugger it seems that the s2n_init succeeds and the s2n_fips_init also returns success. When the S3 upload task was being scheduled I ran the s2n_get_fips_mode and it also returned with S2N_FIPS_MODE_ENABLED. I also tried to see what happens when the s2n_connection_new is called, but it didn't seem to be called at all.

After checking the call stack further of the S3 upload task, which uses the Aws::S3::S3Client, when the PutObject is called it seems to be using CurlHttpClient to set up the connection using the curl API and submit the Aws::Http::HttpRequest, so I suppose the SSL connection handling is being taken care of by the curl library. So it seems to me that in this use case the S2N library is not used by the aws-sdk-cpp so the that's why I did not encounter the failure.