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.
Sobre el autor
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.
Más similar
Navegar por canal
Automatización
Las últimas novedades en la automatización de la TI para los equipos, la tecnología y los entornos
Inteligencia artificial
Descubra las actualizaciones en las plataformas que permiten a los clientes ejecutar cargas de trabajo de inteligecia artificial en cualquier lugar
Nube híbrida abierta
Vea como construimos un futuro flexible con la nube híbrida
Seguridad
Vea las últimas novedades sobre cómo reducimos los riesgos en entornos y tecnologías
Edge computing
Conozca las actualizaciones en las plataformas que simplifican las operaciones en el edge
Infraestructura
Vea las últimas novedades sobre la plataforma Linux empresarial líder en el mundo
Aplicaciones
Conozca nuestras soluciones para abordar los desafíos más complejos de las aplicaciones
Programas originales
Vea historias divertidas de creadores y líderes en tecnología empresarial
Productos
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Servicios de nube
- Ver todos los productos
Herramientas
- Training y Certificación
- Mi cuenta
- Soporte al cliente
- Recursos para desarrolladores
- Busque un partner
- Red Hat Ecosystem Catalog
- Calculador de valor Red Hat
- Documentación
Realice pruebas, compras y ventas
Comunicarse
- Comuníquese con la oficina de ventas
- Comuníquese con el servicio al cliente
- Comuníquese con Red Hat Training
- Redes sociales
Acerca de Red Hat
Somos el proveedor líder a nivel mundial de soluciones empresariales de código abierto, incluyendo Linux, cloud, contenedores y Kubernetes. Ofrecemos soluciones reforzadas, las cuales permiten que las empresas trabajen en distintas plataformas y entornos con facilidad, desde el centro de datos principal hasta el extremo de la red.
Seleccionar idioma
Red Hat legal and privacy links
- Acerca de Red Hat
- Oportunidades de empleo
- Eventos
- Sedes
- Póngase en contacto con Red Hat
- Blog de Red Hat
- Diversidad, igualdad e inclusión
- Cool Stuff Store
- Red Hat Summit