OpenSSL 3.0 — Accelerating forwards

Last year, OpenSSL celebrated its 20^th birthday. It was born of the earlier SSLeay project, which had begun some years before. The age of the project and the development history over those years evolved into a code base that wasn’t always simple and easy to maintain.

The 3.0 project is the first major overhaul of the internal dispatch structure throughout the library. The clunky methods of connecting between a user’s request and the associated implementation are being removed and replaced by one uniform mechanism.

Two legacy areas, in particular, were problematic (for complexity and maintainability) and didn’t fully provide what was later needed:

• Engines, which allow for third party loadable modules that provide access to acceleration, cryptographic offloading, and HSM devices.
• The Federal Information Processing Standard (FIPS) module, which is necessary for use within certain government contexts.

Both contained hundreds of hooks in the code in order for them to operate. Often the hooks interacted with each other in unexpected ways. With the release of OpenSSL 1.1 in August 2016, the FIPS code was completely removed because it was considered unsuitable for long term support and needed to be replaced by something rather different.

 
The groundwork for the OpenSSL 3.0 changes was laid out in OpenSSL 1.1. In addition to removing all FIPS references, most internal data structures were made opaque. This critical change permits the project to extend and expand functionality and rework internal infrastructure without having to do it while wearing a straitjacket.

Before OpenSSL 1.1, everything was open and available to users and many APIs that should have been for internal use only were globally visible and used by applications. Needless to say, the transition for our users to OpenSSL 1.1 was not without pain. Any future transitions need to be as smooth and painless as possible.

What’s new in 3.0

The primary solution being introduced into OpenSSL 3.0 is a concept of a provider, which contains a number of algorithm implementations. The important difference between 3.0’s providers and earlier engines is the level at which the APIs that cross the boundary (from OpenSSL and into the implementation code in a provider) occur. Engines presented a very low-level interface that required more knowledge of the OpenSSL internals than was appropriate; whereas providers present an interface that performs entire cryptographic operations at a higher level.

In addition to introducing providers, OpenSSL 3.0 is also introducing a number of other features to make selection of specific implementations easier.

Instead of implementations always being chosen by a small integer identifier and perhaps linked to a specific engine, 3.0 selects algorithms based on a library context and properties. The introduction of the library context allows multiple distinct security regions within an application, with each library context being able to limit what cryptographic operations and which providers are available when using it.

Properties allow for the selection of a specific algorithm from multiple implementations. For example, if you must have a FIPS-validated implementation you can specifyfips=yes as part of the lookup and all algorithms without this property will be excluded from the search.

One of the stated aims for user’s migrating from OpenSSL 1.1.1 to OpenSSL 3.0, is that 98% of typical applications should run after a simple recompilation and relinking. This means that the outward facing APIs are going to be minimally touched, despite the large-scale renovations happening at the lower levels. Thus far into the 3.0 project, this still looks to be achievable. This doesn’t mean that applications won’t want to make changes; as some changes will be required to take advantage of new features.

Where the project is at

The current timeline has code completion by the end of 2019. The FIPS lab will then review and test the FIPS provider as the first step in a FIPS validation and the expectation is a Q2 2020 submission of the completed provider to NIST for validation.

If you want a head start adopting the changes in OpenSSL 3.0, the recommendation is to ensure that your application works with OpenSSL 1.1.1. For those using older versions of OpenSSL, version 1.0.2 is going ‘end of life’ and will cease to be supported at the end of 2019. There is an option for extended support, but it is paid for.

For more information see the project website or leave a comment below.

Contributor: Tim Hudson

Paul Dale is a management committee member of the OpenSSL project.

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.