-
Notifications
You must be signed in to change notification settings - Fork 735
Improve support for OpenSSL 3.x series with validated FIPS 140-3 modules #5446
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
…S provider In OpenSSL providers can be mixed and matched. Meaning whilst one is compiling against libcrypto 3.5, the FIPS provider can be 3.0.8, 3.0.9, 3.1.2 or even from a non-openssl codebase (symcrypt, wolfcrypt, etc). Thus this heuristic check of libcrypto is incorrect. For example both Ubuntu 22.04 and Amazon Linux 2023 have 3.0 OpenSSL provider with FIPS 140-3 certification. OpenSSL upstream has 3.1.2 with FIPS 140-3. Etc. Making this check test the version of the FIPS provider would also be incorrect, as there are FIPS providers of 3.0.x versions for both FIPS 140-2 and FIPS 140-3. Also there are providers based on OpenSSL code that do not use OpenSSL upstream versioning scheme (SUSE) or the ones not based on OpenSSL code at all (notably symcrypt, wolfcrypt). Thus simply remove this restriction, and start supporting FIPS 140-3 certified modules.
Correct statements around FIPS 140-3 which have evolved, based on updated IG guidance and security policies of validated FIPS 140-3 modules for OpenSSL.
Asking users to change global openssl config is cumbersome, and instead it is easier to self-load default provider anyway. Separately, maybe MD5, MD5-SHA1, SHA1, SHA224 support should be removed altogether, or only loaded opportunistically, as it is unlikely to be used by any default policies anymore. Or is at all relevant in OpenSSL FIPS context. Note that some deployments already default to loading the default provider - for example Azure Linux in FIPS. Whilst others choose not to - Ubuntu & Chainguard.
I see |
if (!OSSL_PROVIDER_available(NULL, "default")) { | ||
/* System is configured without the default provider, but we are | ||
* about to fetch MD5 and SHA1 from it below, note note sure if | ||
* this should be conditional and opportunistic, as most | ||
* policies no longer use SHA1, and even SHA224 is weak these | ||
* days. Similar approach is taken in python to fetch MD5 when | ||
* usedforsecurity=False */ | ||
OSSL_PROVIDER_load(NULL, "default"); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Historically, s2n-tls does not configure Openssl for customers. Any changes we make will affect other libraries / application use of Openssl. If we load "default" here for NULL library context, we're loading "default" globally with no indication of how that will affect other code that depends on Openssl. We require that the application configure Openssl as needed / desired.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ack - but the other documentation in s2n-tls README explicitly tells end user to load globally and system-wide for all applications and the system, including s2n-tls but also any other system apps.
My ideal preference is to actually not load the default provider at all - and instead not crash and silently not allow MD5 / SHA1 policies etc, and be more oportunistic. Right now s2n-tls crashes if MD5 is not there, and default provider is not loaded.
Would it be acceptable to make MD5, SHA1, MD5-SHA1 optional when default provider has not already been loaded by the user in the global config and/or within the app context that uses s2n-tls?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be acceptable to make MD5, SHA1, MD5-SHA1 optional when default provider has not already been loaded by the user in the global config and/or within the app context that uses s2n-tls?
That would be the preferred way to do it. The problems you'll run into (if I remember correctly from the last time I poked at this) are 1) lots of old tests assume those algorithms are always available 2) there is currently no existing mechanism to mark hash algorithms available / not available. It might also affect protocol version negotiation: if the legacy hashes aren't available, only TLS1.2+ can be negotiated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, but like effectively all FIPS is now TLS1.2+ only in OpenSSL context => the non-extended-master-secret TLSv1.2 has been retired, which needs at least openssl 1.1.1 which has tlsv1.2 and tlsv1.3 support. And if one otherwise compiles openssl in seclevel 2 by default, and sets min prototocl to tlsv1.2 it is a strong indicator the user does not want these legacy algorithms.
Which is quite contratry to what s2n-tls stands for - to be a universal terminator, with own implementation and configs of arbitrary tls feature sets.
Let me ponder things more around here.
* | ||
* However most FIPS 140-3 implementation raise an indicator and allow | ||
* doing so. This implementation does not rely on such indicators. | ||
* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even if we don't directly check indicators, we should not knowingly violate the FIPS 140-3 rules. This comment documents that we're aware that "digest-then-sign" is not supported by FIPS 140-3 modules for ECDSA verify or RSA sign/verify based on the tests defined for FIPS 140-3 modules. If we want to advertise support for Openssl + FIPS 140-3 and remove that README warning about only supporting FIPS 140-2, then we must make "digest-and-sign" work for Openssl.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK!
|
||
When running in FIPS mode with OpenSSL, precise supported runtime configurations depend on the security policy of your FIPS provider. For example, key sizes and algorithms will be enforced by the FIPS provider, even if s2n-tls is configured to attempt to use them. Note runtime indicators are not checked, some usage might be successful but in unapproved mode. Please check approved and unapproved services and service indicators in the security policy of your FIPS provider. In additiona, s2n-tls in FIPS mode blocks support for RSA 1024 certificates (https://github.com/aws/s2n-tls/issues/5200) or ChaChaPoly (https://github.com/aws/s2n-tls/issues/5199), even if allowed by the configured security policy. As with non-FIPS OpenSSL, RC4 is also not supported. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When running in FIPS mode with OpenSSL, precise supported runtime configurations depend on the security policy of your FIPS provider. For example, key sizes and algorithms will be enforced by the FIPS provider, even if s2n-tls is configured to attempt to use them. Note runtime indicators are not checked, some usage might be successful but in unapproved mode. Please check approved and unapproved services and service indicators in the security policy of your FIPS provider. In additiona, s2n-tls in FIPS mode blocks support for RSA 1024 certificates (https://github.com/aws/s2n-tls/issues/5200) or ChaChaPoly (https://github.com/aws/s2n-tls/issues/5199), even if allowed by the configured security policy. As with non-FIPS OpenSSL, RC4 is also not supported. | |
When running in FIPS mode with OpenSSL, precise supported runtime configurations depend on the security policy of your FIPS provider. For example, key sizes and algorithms will be enforced by the FIPS provider, even if s2n-tls is configured to attempt to use them. Note runtime indicators are not checked, some usage might be successful but in unapproved mode. Please check approved and unapproved services and service indicators in the security policy of your FIPS provider. In addition, s2n-tls in FIPS mode blocks support for RSA 1024 certificates (https://github.com/aws/s2n-tls/issues/5200) or ChaChaPoly (https://github.com/aws/s2n-tls/issues/5199), even if allowed by the configured security policy. As with non-FIPS OpenSSL, RC4 is also not supported. |
Release Summary:
Improve support for modern OpenSSL 3.0 deployments as used by AmazonLinux 2023, Ubuntu 22.04, RHEL 10, SUSE 16, Chainguard, etc.
Resolved issues:
Not sure if there are issues about this, but this improves OpenSSL FIPS 140-3 integration.
Description of changes:
Currently s2n-tls has a version block on up to date libcrypto versions, as an indirect assertion of not supporting FIPS 140-3 validated OpenSSL modules.
These changes improve integration with OpenSSL FIPS 140-3 validated builds, many of which now exists for 3.0.x series as well as mix of up to date libcrypto from 3.5 with FIPS providers at 3.0/3.1 version numbers.
Call-outs:
Current implementation contained heuristics, which have bitrotted over time and have been triggering codepaths which heuristic was supposed to block but didn't. Thus these changes effectively lift the arbitrary restriction that was previously imposed.
Testing:
I have tested these changes against variety of OpenSSL versions, with a variety of OpenSSL FIPS modules. As I am original developer, submitter, or user with access to many of them.
I have not extensively tested the non-OpenSSL builds or the OpenSSL 1.x versions, to ensure that proposed changes have no affect on them.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
s2n_fips: lift a heuristic check of libcrypto which doesn't check FIPS provider
In OpenSSL providers can be mixed and matched. Meaning whilst one is compiling
against libcrypto 3.5, the FIPS provider can be 3.0.8, 3.0.9, 3.1.2 or even from
a non-openssl codebase (symcrypt, wolfcrypt, etc).
Thus this heuristic check of libcrypto is incorrect. For example both
Ubuntu 22.04 and Amazon Linux 2023 have 3.0 OpenSSL provider with FIPS
140-3 certification. OpenSSL upstream has 3.1.2 with FIPS 140-3. Etc.
Making this check test the version of the FIPS provider would also be
incorrect, as there are FIPS providers of 3.0.x versions for both FIPS
140-2 and FIPS 140-3. Also there are providers based on OpenSSL code
that do not use OpenSSL upstream versioning scheme (SUSE) or the ones
not based on OpenSSL code at all (notably symcrypt, wolfcrypt).
Thus simply remove this restriction, and start supporting FIPS 140-3
certified modules.
docs: Improve docs and comments
Correct statements around FIPS 140-3 which have evolved, based on
updated IG guidance and security policies of validated FIPS 140-3
modules for OpenSSL.
s2n_hash_algorithms_init: auto load default provider
Asking users to change global openssl config is cumbersome, and
instead it is easier to self-load default provider anyway.
Separately, maybe MD5, MD5-SHA1, SHA1, SHA224 support should be
removed altogether, or only loaded opportunistically, as it is
unlikely to be used by any default policies anymore. Or is at all
relevant in OpenSSL FIPS context.
Note that some deployments already default to loading the default
provider - for example Azure Linux in FIPS. Whilst others choose not
to - Ubuntu & Chainguard.