Fedora 36 and Red Hat Enterprise Linux 9 (RHEL 9) are out, and both ship with OpenSSL 3 that has tighter security defaults and a brand new “provider” architecture. While users were testing the beta and other development versions, issues in interoperability with servers and devices such as Wi-Fi access points showed up and caused some confusion between various uses of the rather overloaded word “legacy” that we would like to clear up.
LEGACY cryptographic policy
Fedora and RHEL provide system-wide configurations that apply to all cryptographic libraries in the crypto-policies package since RHEL 8. This provides more consistency for cryptography across all applications.
There are various policies that system administrators can enable using update-crypto-policies --set POLICYNAME from the crypto-policies-scripts package. One of those is the first encounter with the “legacy” keyword: the LEGACY cryptographic policy generates configuration files for GnuTLS, OpenSSL, NSS, BIND, libkrb5, OpenSSH, OpenJDK and libssh that maximize compatibility with older systems while still providing a minimum level of security over the lifetime of the operating system.
The lifetime of the operating system also explains why the LEGACY crypto-policy on Fedora has lower requirements than its RHEL 9 counterpart. Fedora 36’s lifetime is much shorter than that of RHEL 9, so the configuration shipped with RHEL must hold up longer (and thus be tighter). For example, the Fedora 36 LEGACY cryptographic policy includes support for TLS 1.0, while RHEL 9 requires TLS 1.2 at minimum.
Other notable preconfigured cryptographic policies are DEFAULT and FUTURE. Additionally, the crypto-policies system supports subpolicies that allow enabling or disabling specific features, for example using update-crypto-policies --set DEFAULT:SHA1 to use the default policy, but with support for signatures using the SHA-1 digest. See the crypto-policies(7) manpage, the Red Hat Customer Portal, and previous coverage of crypto-policies in this blog for more details, including information on how to define your own policies and subpolicies.
The OpenSSL legacy provider
Fedora 36 and RHEL 9 both ship OpenSSL 3 for the first time, and the OpenSSL developers introduced a concept called “providers” in this version. Providers contain implementations of cryptographic primitives grouped by specific properties. For example, the OpenSSL FIPS provider contains implementations that are undergoing validation according to NIST’s Cryptographic Module Validation Program.
This is where we meet the second instance of “legacy” we’re covering today: the OpenSSL legacy provider. The OpenSSL developers have decided to move a number of outdated algorithms into this provider which isn’t loaded by default and must be enabled explicitly — either through configuration or programmatically — if applications need to use any of these algorithms.
The choices made by the OpenSSL team on which algorithms are “legacy” are rather conservative: the RIPEMD-160 hash function, the RC4, RC5, and single DES encryption algorithms as well as the PBKDF1 key derivation function are the most prominent algorithms that are no longer available by default in OpenSSL.
Applications that still require those deprecated algorithms for special purposes usually load the legacy provider on demand where needed. As a consequence, system administrators should rarely, if ever, have to enable the OpenSSL legacy provider manually. In FIPS mode, these algorithms will be unavailable.
Unsafe legacy renegotiation in TLS
Our final stop on today’s journey across the land of word “legacy” brings us to Transport Layer Security or TLS, also often known by its predecessor’s name, SSL. Starting with OpenSSL 3, and thus Fedora 36 and RHEL 9, TLS connections expect the server to send the renegotiation_info extension, specified in 2010 in RFC5746 in response to CVE-2009-3555. Unfortunately, it seems some servers out there still do not yet support this extension, which causes connections to fail with a rather cryptic message that contains our keyword:
SSL_connect error:0A000152:SSL routines::unsafe legacy renegotiation disabled
In particular, older enterprise Wi-Fi hardware seems to have some catching up to do with the relevant standards. You can follow the discussion and witness the term confusion for Fedora 36 in bug 2072070, and for RHEL 9 in bug 2077973.
Conclusion
“Legacy” has many uses in cryptography, and this post can only cover a small subset. Nonetheless, we hope that our discussion of these three uses helps you distinguish these cases and draw the right conclusions. If you would like to learn more about the security capabilities within RHEL, the Red Hat Product Security Center is a great place to get started.
저자 소개
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.
유사한 검색 결과
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
오리지널 쇼
엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리
제품
- Red Hat Enterprise Linux
- Red Hat OpenShift Enterprise
- Red Hat Ansible Automation Platform
- 클라우드 서비스
- 모든 제품 보기
툴
체험, 구매 & 영업
커뮤니케이션
Red Hat 소개
Red Hat은 Linux, 클라우드, 컨테이너, 쿠버네티스 등을 포함한 글로벌 엔터프라이즈 오픈소스 솔루션 공급업체입니다. Red Hat은 코어 데이터센터에서 네트워크 엣지에 이르기까지 다양한 플랫폼과 환경에서 기업의 업무 편의성을 높여 주는 강화된 기능의 솔루션을 제공합니다.