OpenSSL 4.0 Ships With Encrypted Client Hello, Post-Quantum Algorithms, and a New Two-Year Release Cadence
OpenSSL 4.0.0 landed on April 14 as the library's first major version bump since 2018, adding ECH, post-quantum hybrid key exchange, and removing the legacy engine API and SSLv3.
Editor's Note ·
- Clarification:
- The article quotes Help Net Security as describing ECH as designed "to conceal server name information from passive observers." The Help Net Security source actually states that ECH "allows the client hello message to be encrypted so passive observers cannot read the server name a client is connecting to." The meaning is equivalent but the quoted text is a paraphrase rather than verbatim text.
Overview
OpenSSL 4.0.0 was released on April 14, 2026, marking the library’s first major version increment since OpenSSL 1.1.1 in September 2018. The release, announced by Matt Caswell, Executive Director of the OpenSSL Foundation, removes a decade’s worth of deprecated protocols and APIs while introducing support for Encrypted Client Hello and post-quantum hybrid key exchange algorithms. Three weeks after the release, OpenSSL Core Team member Tim Hudson used the occasion to announce a formalized two-year release cadence that aims to give the cryptography ecosystem predictable upgrade windows.
What’s New in 4.0
Encrypted Client Hello
The most visible user-facing addition is support for Encrypted Client Hello, specified in RFC 9849. According to Help Net Security, ECH is designed “to conceal server name information from passive observers.” Cybersecurity researcher Paul Duplys, writing for TLS Port, describes the problem ECH addresses as “the last major plaintext metadata leak in TLS 1.3: the Server Name Indication (SNI) field.” The implementation uses “Hybrid Public Key Encryption” to encrypt the sensitive fields while presenting a cover value to network observers, preventing passive observers from identifying which server a client is connecting to even when the underlying IP is known.
Post-Quantum Algorithms
OpenSSL 4.0 ships post-quantum support as a production feature rather than an experimental add-on. The release adds the hybrid key exchange group curveSM2MLKEM768, which pairs the classical SM2 elliptic curve with ML-KEM-768, the NIST-standardized Module-Lattice Key Encapsulation Mechanism, as well as the ML-DSA-MU digest algorithm and the cSHAKE function per NIST SP 800-185. According to the official release notes, the library also adds support for negotiated FFDHE key exchange in TLS 1.2 in accordance with RFC 7919.
FIPS Improvements
The FIPS self-test process gains a deferred-execution mode via the openssl fipsinstall -defer_tests flag, allowing FIPS self-tests to be scheduled and run as needed rather than at module installation time, per the release announcement.
Major Removals
Engine API
The most disruptive change for existing integrations is the complete removal of the engine API, which had provided a mechanism for integrating external cryptographic hardware and software modules. Duplys notes that “engines and providers served the same purpose, but the two interfaces coexisted uneasily, creating maintenance burden, internal complexity, and subtle behavior differences.” The API was deprecated when the provider framework was introduced in OpenSSL 3.0; 4.0 makes that migration mandatory. FireDaemon Technologies summarizes the directive for affected developers: “The no-engine build option and OPENSSL_NO_ENGINE macro are now always present. Custom engine integrations will not work. Migrate to providers.”
Legacy Protocols
SSLv3 support is removed in full. The protocol had been disabled by default since OpenSSL 1.1.0 in 2016, following its deprecation in 2015 after the POODLE attack. SSLv2 Client Hello compatibility support is also eliminated. The c_rehash script, which had long-standing documented security concerns, is replaced by the openssl rehash command.
API-Level Changes
Help Net Security notes additional breaking changes: ASN1_STRING has been made opaque, X.509 processing functions now include const qualifiers, and OPENSSL_cleanup() now runs via a global destructor rather than atexit(). Deprecated custom EVP cipher, digest, and key methods have also been removed. As FireDaemon cautions: “Code that compiled cleanly against OpenSSL 3.x may not compile against 4.0 without changes.”
Support Window and Migration Guidance
OpenSSL 4.0 is a non-LTS release. As LWN.net reports, support runs until May 14, 2027 — approximately 13 months. Organizations requiring a longer support window are encouraged to remain on OpenSSL 3.5 LTS, which was released April 8, 2025 and is supported until April 8, 2030, according to the OpenSSL roadmap.
A Formalized Release Cadence
On May 7, 2026, the OpenSSL Library published a post reflecting on the project’s future release schedule. Tim Hudson, speaking at ICMC26, announced a shift from feature-driven major releases to a time-based cadence. “Following the release of 4.0, the first major release since 2018, we now commit to a major release every two years,” he stated, according to the OpenSSL Library blog.
Under the new schedule, OpenSSL 4.1 is due in October 2026, followed by OpenSSL 4.2 as an LTS release in April 2027 and OpenSSL 5.0 in October 2027. The blog notes that “the final 4.x release will be supported for the entire 5.x release cycle. This gives significant flexibility for projects that depend on OpenSSL to decide the appropriate moment to move to a more recent version.”
What We Don’t Know
The release announcement does not include figures on how many downstream projects currently depend on the engine API, how many have completed or begun migration to providers, or the scope of the migration effort across the broader open-source ecosystem. Community discussion on LWN raised questions about post-quantum implementation documentation, testing transparency, and formal bug reporting channels for the new cryptographic implementations, though the OpenSSL Foundation has not yet addressed these publicly.
Analysis
OpenSSL’s position as the default TLS library for a vast share of internet infrastructure means that 4.0’s changes will ripple through operating system distributions, container images, and embedded systems on a multi-year timeline. The removal of the engine API in particular represents a forced migration for any custom hardware security module integration still relying on the old interface — a category that includes industrial control systems, payment hardware, and government-certified deployments. The formalized two-year cadence addresses a long-standing complaint that OpenSSL major releases were unpredictable in both timing and scope. Whether the cadence holds through the 5.0 cycle will be the real test of the new policy.