Over five months after its previous 3.4 version, the team behind OpenSSL has just announced the release of OpenSSL 3.5, introducing several notable enhancements.
As the main highlight, the default encryption cipher for the req, cms, and smime applications has been changed from des-ede3-cbc
to the more powerful aes-256-cbc
.
Furthermore, the default TLS-supported groups list is now configured to include and favor hybrid post-quantum cryptography (PQC) KEM groups, removing some lesser-used groups in the process. Developers should also note that the default TLS keyshares now offer X25519MLKEM768
and X25519
to bolster key establishment options.
Another important point worth highlighting is the deprecation of all BIO_meth_get_*()
functions. While this may prompt changes in legacy code, it sets the stage for more modern approaches to bio-layer functionality.
Meanwhile, organizations that rely heavily on TLS can look forward to support for multiple TLS keyshares and improved TLS key establishment group configurability—ideal for those seeking maximum flexibility in their cryptographic setups.
Users will also be excited to learn that OpenSSL 3.5.0 offers server-side QUIC (RFC 9000) support, plus compatibility with third-party QUIC stacks, including 0-RTT support for faster handshakes. In addition, the release advances post-quantum readiness by adding PQC algorithms (ML-KEM, ML-DSA, and SLH-DSA).
Furthermore, new configuration options have been introduced, like no-tls-deprecated-ec
to disable support for TLS groups deprecated in RFC8422 and enable-fips-jitter
to incorporate JITTER seed sources for the FIPS provider.
For larger deployments requiring cryptographically nimble workflows, central key generation in CMP and opaque symmetric key objects (EVP_SKEY) bring convenience and enhanced control.
Additionally, the release provides API support for pipelining in provided cipher algorithms, a welcome improvement for those optimizing high-performance applications.
Lastly, a known issue may affect some users: calling SSL_accept
on objects returned from SSL_accept_connection
results in an unexpected error instead of advancing the handshake as intended.
For now, developers can circumvent this by calling SSL_do_handshake
instead, though a permanent fix is already planned for OpenSSL 3.5.1.
The release’s changelog contains a detailed list of all changes in OpenSSL 3.5.