Skip to content

Conversation

xnox
Copy link

@xnox xnox commented Jul 30, 2025

  • s2n_fips: lift a heuristic check of libcrypto which doesn't check FIPS provider
  • docs: Improve docs and comments
  • s2n_hash_algorithms_init: auto load default provider

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.

xnox added 3 commits July 30, 2025 13:07
…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.
@xnox xnox requested a review from dougch as a code owner July 30, 2025 12:39
@xnox xnox changed the title ossl fips 140 3 Improve support for OpenSSL 3.x series with validated FIPS 140-3 modules Jul 30, 2025
@xnox
Copy link
Author

xnox commented Jul 30, 2025

I see error: code should be clang-formatted [-Wclang-format-violations] in the personal CI checks, I will try to fix all that.

Comment on lines +62 to +70
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");
}
Copy link
Contributor

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.

Copy link
Author

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?

Copy link
Contributor

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.

Copy link
Author

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.

Comment on lines +88 to +91
*
* However most FIPS 140-3 implementation raise an indicator and allow
* doing so. This implementation does not rely on such indicators.
*
Copy link
Contributor

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.

Copy link
Author

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants