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.
À propos de l'auteur
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.
Contenu similaire
Parcourir par canal
Automatisation
Les dernières nouveautés en matière d'automatisation informatique pour les technologies, les équipes et les environnements
Intelligence artificielle
Actualité sur les plateformes qui permettent aux clients d'exécuter des charges de travail d'IA sur tout type d'environnement
Cloud hybride ouvert
Découvrez comment créer un avenir flexible grâce au cloud hybride
Sécurité
Les dernières actualités sur la façon dont nous réduisons les risques dans tous les environnements et technologies
Edge computing
Actualité sur les plateformes qui simplifient les opérations en périphérie
Infrastructure
Les dernières nouveautés sur la plateforme Linux d'entreprise leader au monde
Applications
À l’intérieur de nos solutions aux défis d’application les plus difficiles
Programmes originaux
Histoires passionnantes de créateurs et de leaders de technologies d'entreprise
Produits
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Services cloud
- Voir tous les produits
Outils
- Formation et certification
- Mon compte
- Assistance client
- Ressources développeurs
- Rechercher un partenaire
- Red Hat Ecosystem Catalog
- Calculateur de valeur Red Hat
- Documentation
Essayer, acheter et vendre
Communication
- Contacter le service commercial
- Contactez notre service clientèle
- Contacter le service de formation
- Réseaux sociaux
À propos de Red Hat
Premier éditeur mondial de solutions Open Source pour les entreprises, nous fournissons des technologies Linux, cloud, de conteneurs et Kubernetes. Nous proposons des solutions stables qui aident les entreprises à jongler avec les divers environnements et plateformes, du cœur du datacenter à la périphérie du réseau.
Sélectionner une langue
Red Hat legal and privacy links
- À propos de Red Hat
- Carrières
- Événements
- Bureaux
- Contacter Red Hat
- Lire le blog Red Hat
- Diversité, équité et inclusion
- Cool Stuff Store
- Red Hat Summit