OpenSSL 3.5 LTS Brings Server-Side QUIC, Post-Quantum Crypto, and Performance Enhancements

Major update introduces QUIC protocol support, hybrid post-quantum TLS groups, and streamlined defaults for modern security environments

OpenSSL 3.5 has officially landed, bringing a wave of important updates for system administrators, cloud providers, and developers who rely on this foundational cryptographic library. As the latest Long-Term Support (LTS) release, OpenSSL 3.5 is packed with enhancements that modernize its security posture and broaden its applicability for cutting-edge use cases — including secure transport protocols, post-quantum cryptography, and large-scale system integration.

QUIC Support Now Built-In

The highlight of this release is full server-side support for QUIC (RFC 9000) — the high-performance, low-latency transport protocol that underpins HTTP/3. This makes OpenSSL 3.5 a first-class citizen in next-generation networking environments, especially for cloud-native services and latency-sensitive workloads such as streaming, gaming, and AI inference platforms.

Additionally, OpenSSL 3.5 introduces compatibility with third-party QUIC stacks, including 0-RTT connections, enabling sysadmins and developers to leverage QUIC’s rapid handshake and mobility features without sacrificing cryptographic rigor.

“QUIC is set to reshape how we think about transport-layer security. Native support in OpenSSL simplifies deployment pipelines and expands TLS-based authentication beyond traditional TCP,” says Jon F., a senior cloud infrastructure engineer at a major US provider.

Post-Quantum Security Takes a Step Forward

With the quantum threat looming closer each year, OpenSSL 3.5 includes experimental support for post-quantum cryptographic (PQC) algorithms, including:

• ML-KEM (for key exchange),
• ML-DSA and SLH-DSA (for digital signatures).

Hybrid TLS key exchange groups now prioritize combinations like X25519 + ML-KEM768, ensuring backward compatibility while preparing systems for NIST-approved post-quantum transition paths.

Default TLS group lists have been updated to reflect these hybrid preferences, while unused legacy groups were removed to reduce attack surfaces.

Security Defaults Modernized

A number of configuration and default behaviors have also been updated:

• Default cipher for req, cms, and smime commands is now AES-256-CBC instead of outdated DES-EDE3-CBC.
• TLS keyshares default to X25519 and X25519MLKEM768 for greater forward secrecy and quantum readiness.
• Deprecated: BIO_meth_get_*() functions are no longer recommended and may be removed in future versions.

These changes reflect industry-wide best practices for stronger, future-proofed cryptography and simpler baseline hardening for sysadmins.

Other Notable Features

OpenSSL 3.5 also includes:

• New configuration flags:
  • no-tls-deprecated-ec: disable support for legacy EC groups from RFC 8422.
  • enable-fips-jitter: enables JITTER entropy source in FIPS mode.
• CMP enhancements: Adds support for centralized key generation.
• EVP_SKEY: New support for opaque symmetric key objects.
• Enhanced TLS configurability: Improved multiple keyshare handling and pipelining APIs for cipher algorithms.

Known Issue: SSL_accept Bug

There’s a known issue in version 3.5.0 where calling SSL_accept() on connections returned by SSL_accept_connection() will not advance the handshake as expected. This can be temporarily mitigated by using SSL_do_handshake() instead. A fix is slated for OpenSSL 3.5.1.

For Sysadmins: Why It Matters

• TLS and QUIC in one stack: Reduces complexity for secure application deployment, especially for those adopting HTTP/3 or building microservices at scale.
• Long-Term Support: Version 3.5 is supported through the official LTS window — safe for enterprise environments.
• PQC Ready: Prepares you to comply with upcoming post-quantum mandates from agencies like NIST and NSA.
• Stronger defaults: Makes hardening easier and reduces misconfiguration risk out-of-the-box.

OpenSSL 3.5.0 is available now at https://www.openssl.org/source. It is recommended for testing in staging environments before wide-scale production deployment, especially where TLS, QUIC, or hybrid key exchanges are in scope.

If your infrastructure relies on OpenSSL — and most do — it’s worth digging into this release. The future of secure transport just got faster, more flexible, and more resilient.