Skip to Content

What’s Inside OpenSSL 3.5? The Crypto World Just Got a Major Upgrade

After more than five months since the release of version 3.4, OpenSSL 3.5 is here—and it’s packed with significant cryptographic advancements.

What’s changed under the hood? How does it impact your applications? Should you upgrade now or wait?

I’ll walk you through everything you need to know—from new post-quantum cryptography support and TLS enhancements to modern defaults and API deprecations that may affect legacy systems.

Get Your Free Linux training!

Join our free Linux training and discover the power of open-source technology. Enhance your skills and boost your career! Start Learning Linux today - Free!

Whether you’re managing production infrastructure, writing secure code, or just trying to stay ahead of cryptographic trends, this release brings some big shifts you won’t want to miss. Let’s dive in.

Stronger Defaults, Right Out of the Box

One of the most noticeable changes? OpenSSL has replaced the aging des-ede3-cbc cipher with the much stronger aes-256-cbc as the default for the req, cms, and smime applications.

Potential Impact:

If your automation scripts or legacy systems are hardcoded to expect des-ede3-cbc, you may see errors or compatibility issues when running OpenSSL 3.5. You’ll need to explicitly specify the cipher if backward compatibility is required.

TLS also gets a security facelift. The default supported groups list now prioritizes hybrid post-quantum cryptography (PQC) key encapsulation mechanisms (KEMs), like X25519MLKEM768, while dropping some lesser-used legacy groups. You’ll also see X25519 still in the mix for wider compatibility.

Modernization Under the Hood

OpenSSL 3.5 continues to shed legacy baggage. The BIO_meth_get_*() functions are now deprecated, signaling a push toward more modern handling of BIO-layer operations.

Potential Impact:

Applications using custom BIO methods—common in older enterprise codebases—may fail to compile or behave unexpectedly.

Developers should plan for code updates or refactoring to align with the new APIs.

TLS power users will appreciate the new ability to configure multiple keyshares more flexibly—a big win for tuning cryptographic performance and resilience in diverse environments.

Hello, Server-Side QUIC

Another headline feature is full support for server-side QUIC (RFC 9000), including compatibility with external QUIC stacks and 0-RTT support for lightning-fast handshakes.

That’s great news for developers building high-speed, low-latency applications.

Potential Impact:

Teams integrating QUIC with OpenSSL should double-check third-party QUIC library compatibility and test 0-RTT behavior in production-like environments. Differences in handshake behavior could surface in load balancers or edge proxies.

Post-Quantum Ready

The march toward post-quantum security continues with the addition of PQC algorithms like ML-KEM, ML-DSA, and SLH-DSA.

These additions not only enhance future-proofing but also align OpenSSL with ongoing global efforts in quantum-safe cryptography.

Potential Impact:

Organizations with strict compliance requirements may need to audit these new algorithms before enabling them in production, especially if interoperability with older clients or libraries is needed.

New Config Options and API Improvements

OpenSSL 3.5 introduces fresh configuration flags:

  • no-tls-deprecated-ec disables TLS groups deprecated by RFC 8422.
  • enable-fips-jitter enables JITTER-based entropy for the FIPS provider.

For large-scale deployments, new features like centralized key generation in CMP and the new EVP_SKEY (opaque symmetric key objects) offer greater control and easier key management.

Developers will also welcome the new support for pipelining in provided cipher algorithms—especially useful for performance-intensive workloads.

Known Issue to Watch

One caveat: calling SSL_accept on objects returned from SSL_accept_connection currently triggers an error instead of progressing the handshake. The recommended workaround for now is to use SSL_do_handshake instead. A fix is already lined up for version 3.5.1.

Potential Impact:

If you’re building server-side TLS logic that relies on SSL_accept_connection, this bug could break existing flows. Until the fix arrives, you’ll need to patch your code to call SSL_do_handshake manually.

The full changelog for OpenSSL 3.5 is available on the project’s website.

Jeffery

Monday 14th of April 2025

Really solid update. Love seeing stronger defaults and broader algorithm support—especially the continued push for post-quantum readiness. OpenSSL might be behind the scenes, but this release reminds us how much of the internet quietly depends on it. Great work from the team.