OpenSSL 3.0: What you should know

OpenSSL 3.0 brings with it several notable changes, including a new versioning system and a different open-source license structure. OpenSSL 3.0 constitutes a major version and is NOT backwards compatible. Additionally, OpenSSL 3.0 includes a new module which enforces only FIPS compliant cryptography, though as of this writing it has not finished the third-party validation required.

Previous versions of OpenSSL relied on the iconic “lettering” system, such as OpenSSL 1.1.1k. Going forward, OpenSSL will be more closely aligned with semantic versioning utilizing a version string such as:

Where 3 denotes the major version, 0 denotes the minor milestone, and 1 represents the patch level. This is useful as it encapsulates more information directly in the version string. If the patch level changes, there is likely a security fix worth applying whereas if the minor version changes dollars to donuts you will be having a conversation with your application vendor!

OpenSSL has historically been licensed under its own hodgepodge of licensing terms. Finally, the OpenSSL project has been released under a standard open-source license, specifically Apache License v2. modifications to the software be explicitly enumerated. From a security standard, the Apache License is a great choice for OpenSSL since it requires that any changes to the source code be explicitly enumerated.

There have been a bevy of breaking API changes in this release, some expected, and some unexpected. Historically APIs in OpenSSL have been bifurcated into two buckets: “high-level” APIs which provide a layer of abstraction between the user and their choice of algorithm (though the algorithm selection may be a parameter to one of these high-level APIs), and “low-level” APIs which are algorithm specific. The high-level APIs have reached a level of maturity where that using the low-level APIs no longer provides the developer with a tangible benefit, and so future versions of OpenSSL will likely remove these low-level APIs entirely. For now, you can use them, but compilation will be littered with warnings.

In version 4.13 of the Linux kernel, support was released for user-space processes to offload certain cryptographic operations to the operating system, which results in some impressive performance improvements. Supporting Kernel TLS is significant in that since 2017 when 4.13 was released, taking advance of Kernel TLS often meant forking OpenSSL to do so. Many of these forks are available on github for OpenSSL 1.1.1, however this kind of fragmentation can lead to seriously diminished security. In order to minimize the footprint in the operating system’s codebase while maximizing performance gains, only the actual symmetric portion of what’s called the “TLS Record Layer” is processed directly by the kernel – the TLS handshake, even when using Kernel TLS, is brokered by the userland application (in this case OpenSSL). This allows the syscall sendfile() man7.org/linux/man-pages/man2/sendfile.2.html to avoid an unnecessary copy into user space only to ultimately copy it back to kernel space once encrypted. Additionally, utilizing Kernel TLS allows for taking advantage of NICs capable of performing encryption on-the-fly in hardware.

The Federal Information Processing Standards (FIPS) are a set of requirements enforced by the US government which govern cryptographic usage in the public sector. For those not obligated to bend to the standard, leveraging FIPS may actually do more harm than good – FIPS compliant algorithms and tools have gone through a stringent set of third-party validation, but this onerous and expensive validation gauntlet introduces a significant delay when it comes to being able to take advantage of some of the latest and greatest research in the field, even if that research is sound and reasonable. (Elliptic curve cryptography for example is considered by all but the most conservative to be reasonably secure, but FIPS support notoriously lagged behind)

If you are an administrator, hang tight. Application providers have until 2023 to make their codebase compatible with OpenSSL 3.0. If you are a developer, it would be prudent to determine the level-of-effort required to support OpenSSL 3.0. A good majority of developers reliant on OpenSSL don’t need to make any changes except to recompile their application against the new libcrypto. Developers still using the low-level APIs should consider whether now is the appropriate time to change their code to utilize the high-level APIs in order to future-proof and eliminate those nasty compiler warnings. Finally, checkout the release page to see if some of the more niche compatibility problems cropping up apply to you – github.com/openssl/openssl/issues?page=3&q=is%3Aissue+is%3Aopen

OpenSSL 3.0 is a huge milestone for the OpenSSL project, and some of the codebase simplification made has been long overdue. In many ways, it seems as though these changes back out of some of the quirks the OpenSSL project has been famous for including its bespoke licensing and peculiar version nomenclature. It will take a considerable amount of time before OpenSSL 3.0 reaches the ubiquity of OpenSSL 1.1.1, and longer still before support for that version is eventually sunset.