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.
Sull'autore
Clemens Lang has been part of the Red Hat Crypto Team since January 2022. Prior to his work at Red Hat, he took care of open source packaging, over-the-air updates and security of infotainment systems at BMW. Clemens has also contributed to the MacPorts project since Google Summer of Code 2011.
Altri risultati simili a questo
Ricerca per canale
Automazione
Novità sull'automazione IT di tecnologie, team e ambienti
Intelligenza artificiale
Aggiornamenti sulle piattaforme che consentono alle aziende di eseguire carichi di lavoro IA ovunque
Hybrid cloud open source
Scopri come affrontare il futuro in modo più agile grazie al cloud ibrido
Sicurezza
Le ultime novità sulle nostre soluzioni per ridurre i rischi nelle tecnologie e negli ambienti
Edge computing
Aggiornamenti sulle piattaforme che semplificano l'operatività edge
Infrastruttura
Le ultime novità sulla piattaforma Linux aziendale leader a livello mondiale
Applicazioni
Approfondimenti sulle nostre soluzioni alle sfide applicative più difficili
Serie originali
Raccontiamo le interessanti storie di leader e creatori di tecnologie pensate per le aziende
Prodotti
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Servizi cloud
- Scopri tutti i prodotti
Strumenti
- Formazione e certificazioni
- Il mio account
- Supporto clienti
- Risorse per sviluppatori
- Trova un partner
- Red Hat Ecosystem Catalog
- Calcola il valore delle soluzioni Red Hat
- Documentazione
Prova, acquista, vendi
Comunica
- Contatta l'ufficio vendite
- Contatta l'assistenza clienti
- Contatta un esperto della formazione
- Social media
Informazioni su Red Hat
Red Hat è leader mondiale nella fornitura di soluzioni open source per le aziende, tra cui Linux, Kubernetes, container e soluzioni cloud. Le nostre soluzioni open source, rese sicure per un uso aziendale, consentono di operare su più piattaforme e ambienti, dal datacenter centrale all'edge della rete.
Seleziona la tua lingua
Red Hat legal and privacy links
- Informazioni su Red Hat
- Opportunità di lavoro
- Eventi
- Sedi
- Contattaci
- Blog di Red Hat
- Diversità, equità e inclusione
- Cool Stuff Store
- Red Hat Summit