TLS extension "Extended Master Secret" enforced on RHEL 9.2 and later
Environment
- Red Hat Enterprise Linux 9.2 and later
Issue
Starting with Red Hat Enterprise Linux 9.2 (RHEL 9.2), according to upcoming FIPS-140-3 requirements, we make the Extended Master Secret (EMS - Content from datatracker.ietf.org is not included.RFC 7627) extension mandatory for TLS 1.2 connections on FIPS-enabled systems. TLS 1.3 is not affected. This is a potentially breaking change because legacy clients that do not support EMS or TLS 1.3 cannot connect to FIPS servers based on RHEL 9.2 and vice-versa: RHEL 9.2 clients in FIPS mode cannot connect to servers that support TLS 1.2 as the highest protocol version and do not support EMS.
In practice, it means that since RHEL 9.2 it is impossible in FIPS mode to establish TLS connections with servers using RHEL 6, RHEL 7, and other non-RHEL legacy systems as the TLS implementation on those systems neither support EMS nor TLS 1.3.
There is also a potential interoperability issue with TLS servers written in Go and compiled with Go 1.18 or earlier versions, which support neither EMS nor TLS 1.3 in FIPS mode.
Resolution
For connections that do not require FIPS compliance, use the following workaroud
update-crypto-policies --set FIPS:NO-ENFORCE-EMS
NOTE: The workarounds that Red Hat will provide to disable the requirement for EMS on TLS 1.2 connections will not be FIPS-compliant. The recommendation is to upgrade the other side of the connection to support the TLS 1.2 EMS extension or TLS 1.3, which does not require the EMS extension.
Root Cause
Content from csrc.nist.gov is not included.FIPS 140-3 Implementation Guidance requires that TLS 1.2 can only be used with the Extended Master Secret extension in modules validated after May 16, 2023 (see "D.Q Transition of the TLS 1.2 KDF to Support the Extended Master Secret").
Diagnostic Steps
Modern versions of openssl s_client support the option -tlsextdebug. If EMS is supported, the client will print TLS server extension extended master secret (id=23), len=0 on TLS 1.2 connection to the server in question. Alternatively, also the -trace option can be used like in the following example:
# openssl s_client -connect host:port -trace
The other option is analyzing the TLS handshake using Wireshark or similar tools.
This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.