The arrival de OpenSSL 4.0 marks a major break This major version upgrade is not merely symbolic: it brings incompatible changes, new features focused on privacy and future security, and the retirement of technologies that have been obsolete for years. It is a reference library for SSL/TLS and cryptography, widely used in web servers, enterprise applications, and network devices.
For system administrators, cybersecurity managers, and developers, this version represents a turning point when it comes to updating infrastructureIt introduces improvements such as Encrypted Client Hello and advanced support for post-quantum cryptography, but also removes support for legacy protocols, the engine system, and several APIs, forcing a review of the code and compilation processes before making the switch.
Main new features of OpenSSL 4.0
OpenSSL 4.0 is presented as a major update, with a clear focus on strengthen privacy, modernize the codebase, and clean up legacy baggageThe project team has taken advantage of the major version change to introduce incompatible modifications, remove support for fringe platforms, and adjust the default behavior of several internal components.
Among the most visible changes are the incorporation of Encrypted Client Hello (ECH), the expansion of the catalog of algorithms for post-quantum environments, the deprecation and elimination of historical functions in the handling of X.509 certificates and times, as well as the review of compilation options, scripts and build targets in different operating systems.
Enhanced privacy with Encrypted Client Hello (ECH)
One of the most talked-about advances is the integration of Encrypted Client Hello compliant with RFC 9849ECH allows the Client Hello message of TLS to be encrypted, so that a passive observer on the network cannot access the Server Name Indication (SNI), that is, the name of the server to which the client connects.
This change is especially relevant where the privacy protection and connection metadata It has increasing importance in the regulatory framework and policies of many organizations. The adoption of ECH helps reduce the ability of third parties to profile TLS traffic by identifying specific domains accessed by users and companies.
With OpenSSL 4.0, developers implementing ECH will be able to hide sensitive information from the initial handshakeThis makes passive inspection more difficult and increases the level of confidentiality of connections, both in public services and in corporate environments where regulatory compliance and data protection are prioritized.
Goodbye to SSLv3, SSLv2 Client Hello, and the engine system
The new version definitively breaks with part of the protocol's past, since removes support for SSLv3SSLv3, a standard that had been considered insecure for years and was disabled by default in OpenSSL since version 1.1.0, will now be phased out. Therefore, any application that still depended on SSLv3 will have to migrate to modern TLS to be able to work with the 4.0 branch.
The also disappears SSLv2 Client Hello supportThis feature, which was maintained for historical compatibility but was completely outside of best security practices, is now being removed. Its removal helps reduce the attack surface and simplify the code, aligning OpenSSL with current requirements for robust encryption in infrastructure.
Another structural change is the complete elimination of engine API used to integrate external cryptographic hardware and softwareStarting with OpenSSL 4.0, the no-engine compilation option becomes the only one available, and the OPENSSL_NO_ENGINE macro is always present. This necessitates a review of implementations that exploited custom engines for tasks such as cryptographic acceleration or the use of HSM modules.
At the same time, cuts are also being made. Custom methods inherited from EVP_CIPHER, EVP_MD, EVP_PKEY, and EVP_PKEY_ASN1, along with outdated SSL/TLS versioning methods and error state management functions (such as ERR_get_state() and its state removal variants), consolidating a cleaner API that is more consistent with current needs.
Boost to post-quantum cryptography and new algorithms
Looking ahead, OpenSSL 4.0 is advancing its strategy to preparing for threats arising from quantum computingThe version introduces new hybrid cryptography and digest capabilities, aimed at strengthening key exchanges against potential attacks in a post-quantum scenario.
Among the new features is the hybrid key exchange group curveSM2MLKEM768, which combines classical elements with post-quantum schemes, as well as the ML-DSA-MU fingerprinting algorithm and the cSHAKE function according to NIST SP 800-185. These elements expand the possibilities for designing protocols that are more resistant to future cryptanalytic advances.
In addition, the project adds Support for FFDHE key exchange negotiated over TLS 1.2This follows the guidelines established in RFC 7919. This allows implementations that still operate with TLS 1.2 to benefit from improved finite group Diffie-Hellman parameters, raising the level of security in scenarios where an immediate upgrade to TLS 1.3 is not feasible.
API changes and behavior that affect integrators
For those who maintain applications that link to OpenSSL, version 4.0 introduces Direct modifications to the API that can break existing buildsOne of the key transformations is that the ASN1_STRING type becomes opaque, which limits direct access to its internal structure and forces the use of high-level functions.
Many functions, especially those related to X.509 certificate processing now incorporates const qualifiers in their signatures, adjusting the semantics of immutability and forcing adjustments in code that made less strict assumptions. This can generate warnings or compilation errors in projects that do not update the corresponding definitions.
In the field of time management, there have been Declared obsolete functions such as X509_cmp_time(), X509_cmp_current_time() and X509_cmp_timeframe()The recommended usage is now X509_check_certificate_times(), which involves adapting certificate validation routines that previously relied on the old functions.
Another relevant point is that libcrypto stops performing global cleanup of assigned data through atexit(). Instead, OPENSSL_cleanup() is run as a global destructor or is not launched by default, depending on the configuration. This can affect applications that relied on automatic cleanup at process termination, forcing more explicit resource lifecycle management.
Additionally, BIO_f_reliable(), a feature that It had been broken since branch 3.0 and now it disappears without a direct replacementProjects that still use it will have to redesign the associated logic or adopt other primitives from the library to cover similar needs.
Greater rigor in certificate verification and key derivation
OpenSSL 4.0 strengthens the Strict verification of X.509 certificates when X509_V_FLAG_X509_STRICT is enabledWith this flag enabled, additional checks are performed on the AKID (Authority Key Identifier) ​​extension, tightening validation criteria and aligning the library with more demanding security practices.
In the process of verifying revocation lists (CRL), the new version adds Additional controls to ensure that the validation of revoked certificates is more thoroughThese changes impact environments where PKI management is especially sensitive, such as public administrations, banking, or large corporations that depend on robust trust chains.
They are also introduced Mandatory lower limits on the use of PKCS5_PBKDF2_HMAC when using the FIPS providerThis adjustment seeks to avoid overly weak configurations in key derivation from passwords, which in practice forces the use of minimally strong parameters in environments where FIPS compliance is required, very common in critical sectors.
Compilation settings, supported platforms, and tools
In terms of compilation and platform support, OpenSSL 4.0 takes steps towards a more modern and simplified configurationThe project disables support for obsolete elliptic curves in TLS by default, as specified in RFC 8422, as well as the use of explicit elliptic curves. However, configuration options remain for those who need to reactivate them for occasional compatibility reasons.
Regarding the construction objectives, it was They remove the darwin-i386 and darwin-ppc variantsThis officially excludes very old Apple systems based on i386 and PowerPC/PPC64 architectures. In practice, this shouldn't affect most current deployments, where those platforms have been obsolete for some time, but it formalizes their removal from mainstream support.
Regarding tools, the historical script is being removed, and generating hash indexes for certificates in directories is now the recommended method. Additionally, for FIPS installations, the `-defer_tests` option has been introduced in the `openssl fipsinstall` utility, allowing certain auto-tests to be postponed, which can facilitate deployments in environments with boot time constraints.
On Windows systems, the update adds ability to choose between static or dynamic linking of the Visual C++ runtimeThis flexibility is useful for developers and DevOps teams who package applications for different distribution scenarios, as they can adjust the runtime type based on compatibility requirements or the size of the binaries.
Impact on organizations and developers
In a context where much of the Internet infrastructure and critical services rely on OpenSSL, version 4.0 represents a strategic change that requires planningPublic organizations, cloud providers, financial institutions, and technology companies should carefully evaluate the effects of API changes and protocol retirements, especially on legacy systems or poorly maintained applications.
The incorporation of ECH and the strengthening of post-quantum cryptography can be seen as opportunities to raise the default level of protectionBut at the same time, they require thorough testing in pre-production environments. In many cases, it will be necessary to coordinate development, security, and operations teams to ensure that the transition does not break services or introduce regressions.
For open source projects that rely heavily on OpenSSL, the adaptation will involve Adjust function signatures, review the use of now opaque types and replace retired components such as X.509 timing engines or functions. The advantage is that, once updated, these projects will benefit from a cryptographic foundation more aligned with current standards and with less technical debt.
Overall, OpenSSL 4.0 positions itself as a version of cleaning, modernization and preparation for the medium and long termThis requires investing effort in migration but offers in return clear improvements in privacy, security and internal consistency of the library, key aspects to continue supporting the digital infrastructure on solid cryptographic foundations.
