OpenSSL 4.0 encrypts what TLS has previously revealed

OpenSSL 4.0.0 has been released and brings profound changes to the widely used crypto library. The open source project removes deprecated protocols such as SSLv2 and SSLv3, abolishes the engine concept, introduces new data protection features in the TLS handshake and extends the library towards post-quantum cryptography. At the same time, the developers are cleaning up the API and tightening security-related checks.

OpenSSL is one of the core TLS/SSL implementations and is found in web servers, operating systems, network devices and countless applications. Changes to the library directly impact the securing of network connections, certificate checks and cryptographic operations across large parts of the IT infrastructure.

New cryptography: ECH, post-quantum and more

One of the most important innovations is support for Encrypted Client Heo (ECH) according to RFC 9849. ECH encrypts parts of the TLS handshake – in particular the Server Name Indication (SNI). Until now, third parties such as network operators were able to use the SNI to identify which domain a client was accessing. ECH hides this information, significantly improving data protection at the transport level.

Hybrid key exchange methods such as curveSM2MLKEM768 are also new. They combine classic eiptic curves with post-quantum algorithms and thus protect connections today against future attacks by quantum computers: Even if an attacker breaks one of the two methods, the other continues to protect the connection.

The library complements several cryptographic primitives and standards. This includes the cSHAKE function according to SP 800-185 – a more flexible variant of SHA-3 that allows domain-specific hash calculations. There is also support for the signature algorithm ML-DSA-MU and SM2/SM3 according to RFC 8998, which play a role in regulatory contexts, among other things. Additionally, OpenSSL 4.0.0 introduces Key Derivation Functions (KDFs) for SNMP and Secure Real-time Transport Protocol (SRTP), which are used in network management and VoIP scenarios. For TLS 1.2, OpenSSL now also supports standardized Finite Field Diffie-Heman groups (FFDHE) according to RFC 7919. This improves interoperability and avoids unsafe or proprietary parameter selection when exchanging keys.

Stricter validation and FIPS adjustments

Certificate validation is becoming stricter on several levels. In strict mode, OpenSSL now also checks the Authority Key Identifier (AKID), and the CRL check also receives further checks. In FIPS mode, the library now enforces minimum requirements on PBKDF2 – such as the number of iterations – to prevent weak configurations.

Another new feature is the ability to run FIPS self-tests with a delay. This is particularly useful in containerized environments.

Removed protocols, APIs and legacy issues

With version 4.0, OpenSSL cleans things up. In addition to SSLv2 and SSLv3, the engine concept is also going away. In the future, hardware acceleration and external crypto modules will run exclusively via the provider architecture, which has been replacing engines since OpenSSL 3.0. Also removed: fixed TLS version methods, older eiptic curves, various low-level functions and the script c_rehash. Instead, this is what users say openssl rehash use.

There are several changes to the API that may require adjustments to the application code. Numerous functional signatures now carry const-Qualifier, the data type ASN1_STRING is now completely encapsulated – access to its internal fields is only possible via access functions. The output of hex dumps has also been standardized: signatures are displayed in 24-byte blocks, other data in 16-byte blocks. This improves readability and makes the output more consistent. And outdated functions for checking time of certificates give way to the new function X509_check_certificate_times(). There are also changes in runtime behavior: OpenSSL will no longer automatically clean up global data atexit() and relies more heavily on standard functions of the C runtime library, such as snprintf.

For developers and operators, the release means more security and more modern cryptography – while at the same time increasing migration effort. Applications that directly access OpenSSL APIs or use older functions need to be adapted. OpenSSL 4.0 thus lays the foundation for the transition to post-quantum-resistant processes and better data protection in the TLS handshake. Details about the new release can be found on the associated GitHub project page.

(fo)