OpenSSL 4.0.0 is out, the first major version increment since 3.0 in 2021. Two additions will matter most for practitioners building systems that care about TLS privacy or post-quantum preparedness. Encrypted Client Hello (ECH), implementing RFC 9849, encrypts the Server Name Indication field in the TLS handshake — the part that currently leaks which hostname you’re connecting to, even over an otherwise encrypted connection. Until now, ISPs and network observers have been able to passively log which domains a user visits purely from the unencrypted SNI. ECH closes that. On the post-quantum side, the release adds curveSM2MLKEM768, a hybrid key exchange group combining SM2 with ML-KEM-768 (NIST’s standardised post-quantum key encapsulation), and ML-DSA-MU signature algorithms. These aren’t experimental — ML-KEM and ML-DSA are NIST standards — but broad deployment depends on both client and server negotiating support.
The breaking changes are where migration work actually lives. OpenSSL has removed SSLv3 support entirely (it was disabled by default since 1.1.0, but the code remained). More significant for anyone with custom crypto: the engine API is gone. OpenSSL’s engine system was the historical mechanism for plugging in hardware security modules and custom algorithm implementations. It’s been replaced by the provider API introduced in 3.0, but plenty of HSM vendors and legacy codebases still ship engine-based integrations. If your stack depends on a hardware key store accessed via an OpenSSL engine, you need a provider-based replacement before upgrading, and whether your HSM vendor has shipped one is a question worth answering now. The API surface has also changed: many X509 processing functions have gained const qualifiers, and ASN1_STRING is now opaque, so code that manipulates certificate structures directly will require updates.
ECH is the feature with the longest tail to reach. The privacy benefit only materialises when both sides of a connection support it, and browser adoption and CDN-level deployment are still uneven. For self-operated services, enabling ECH requires publishing the relevant DNS records (HTTPS resource records with ECHConfigList), which in practice means coordinating with your DNS provider and ensuring your TLS terminator is running an ECH-capable build. The practical playbook is: enable it at the edge for public-facing services where you control both ends, treat it as aspirational for traffic that routes through CDNs you don’t control, and treat the post-quantum hybrid groups as the higher-priority adoption — they don’t require client-server coordination in the same way, and the threat model (harvest now, decrypt later) means the clock is already running.
The migration priority ranking: first, audit anything that uses OpenSSL engines and verify your hardware vendors have provider-compatible replacements. Second, check certificate validation code against the new strict X509 mode requirements — the release adds AKID verification checks and augmented CRL processing when strict mode is on. Third, enable the post-quantum hybrid key groups on public endpoints. ECH is last only because it requires DNS infrastructure changes and has the most external dependencies.
OpenSSL 4.0.0 is not a disruptive upgrade for applications that use TLS at arm’s length through a framework. It is a substantive migration for anyone who touches X509 processing directly, uses custom engines, or has built infrastructure around the older certificate validation semantics. Check what you actually use before deciding when to move.