The TLS Extended Master Secret and FIPS in Red Hat Enterprise Linux

Almost 10 years ago, researchers identified and presented the “triple handshake” man-in-the-middle attack in TLS 1.2. The vulnerability breaks confidentiality of the connection and allows an attacker to impersonate a client. In response, RFC 7627 introduced the Extended Master Secret Extension for TLS 1.2 in September 2015, which prevents the attack.

All major TLS libraries now support the Extended Master Secret (EMS) and enable it by default. Unfortunately, many older operating systems and embedded devices such as WiFi access points and home routers do not support it. For example, Red Hat Enterprise Linux (RHEL) 7 ships OpenSSL 1.0, which supports neither TLS 1.3, nor the EMS extension in TLS 1.2.

NIST requires EMS after May 16, 2023

The US National Institute of Standards and Technology (NIST) defines the set of standards required for FIPS 140-3 certification, which many of Red Hat’s customers in the public sector require. In May 2022, NIST decided that "[a] new validation, […] submitted more than one year after [May 2022] shall use the extended master secret in the TLS 1.2 KDF." (see FIPS 140-3 IG, section D.Q.) Any cryptographic module submitted for validation or re-validation after May 16th, 2023 must use the Extended Master Secret to be compliant.

RHEL’s submissions for FIPS 140-3 validation

The Red Hat Crypto Team submitted the OpenSSL and NSS modules for RHEL 9.0 for validation on May 15, 2023. They were therefore exempt from this requirement. RHEL 9.0 was the first release submitted for certification against NIST’s new version of the FIPS 140 standards, FIPS 140-3. Submissions for the older standard 140-2 are no longer accepted after September 22, 2021. Due to the large number of changes required to make RHEL comply with FIPS 140-3 and the long queue of validations, this submission only happened after RHEL 9.2 was generally available on May 10, 2023. Therefore, certification of the modules shipped in RHEL 9.2 at general availability was not possible without further changes.

From this position, none of the options are particularly appealing.

Using an explicit FIPS indicator

A feasible option might have been what NIST’s Implementation Guidance for FIPS 140-3 calls a “Security Service Indicator” in section 2.4.C: a separate function that applications can call to verify whether the performed operation was compliant. In this case, the function could have returned true if the TLS connection used the Extended Master Secret, and false otherwise. This is enough to pass certification, but requires that all applications that care about FIPS compliance start checking this indicator. In practice, hardly any applications would do this, and systems would continue to silently make and accept TLS connections without EMS. This satisfies the letter of the requirements but ignores their spirit. NIST clearly wanted to declare TLS connections that do not use EMS non-compliant. We feel that working around this intent silently is not the right thing to do.

Enforce EMS in z-stream

The second possibility is changing the behavior of the cryptographic modules in 9.2 z-stream during the lifetime of RHEL 9.2. The obvious downside is that systems will no longer be able to establish TLS connections without EMS, where such connections did work with RHEL 9.2 when it was initially released. However, this change only affects users running systems in FIPS mode, who presumably use this mode because they need to comply with FIPS regulations.

OpenSSL was the first cryptographic library to implement the change in RHSA-2023:3722. GnuTLS followed, and NSS will soon complete the list of cryptographic libraries that implement TLS key derivation. At the same time, an article in the customer portal explains the new requirement.

Of course, it would have been better if this change had landed in RHEL 9.3 or later, or ideally, only in RHEL 10. Unfortunately, conflicting timelines between the Red Hat Enterprise Linux release schedule and government requirements do not always allow for delaying such changes.

Connecting to old servers

If you need to communicate with endpoints that do not support the TLS Extended Master Secret from a RHEL 9.2 system in FIPS mode, be aware that this is not FIPS-compliant. If that risk is acceptable to you and your auditors, a recent crypto-policies update now offers a workaround. The NO-ENFORCE-EMS policy module relaxes the enforcement of the requirement and allows connections without protections against the triple handshake attack. Executing

$> update-crypto-policies --set FIPS:NO-ENFORCE-EMS

enables the policy module.

For more information about Red Hat Enterprise Linux’s compliance with government standards, see the Compliance Activities and Government Standards page on the customer portal. The Security Hardening documentation has additional information about system-wide cryptographic policies.