OpenSSL 3.0 — Accelerating forwards

By on 21 Oct 2019

Category: Tech matters

Tags: , ,


Blog home

Last year, OpenSSL celebrated its 20th 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.

We recognised that we weren’t all that successful in the past in listening to and taking on board what the community wanted in OpenSSL and we have made a conscious effort to improve that with OpenSSL 3.0, in terms of communicating our plans and incorporating feedback during development — hopefully with a resulting improvement in the user experience when it is released.

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.

Rate this article

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.


  1. Derek Edson

    This delay is really annoying for those of us who are required to use a FIPS validated version of the OpenSSL library. I can understand that delays happen, but this now breaks there previous promise that v3 would be available in plenty of time before the end of life of v1.0.2 in Dec 2019.

    I believe OpenSSL should extend the end of life of v1.0.2 for free until the end of Q2 2020 to allow for developers to update their code.

    The CAPTCHA on this form is rediculous, as it expires before you can type any form of comment.

  2. Dr Paul Dale

    There will be no public extension of 1.0.2 support. That has been stated many times over the past four or so years. There was plenty of notification to have already migrated to the 1.1.1 code line.

    That there will be a gap in FIPS support is unfortunate but the developers working on 3.0 are going as fast as they can. Providing engineering assistance is the best way to expedite the process.

    1. Derek Edson

      Migratation to 1.1.1 code line is not the option, it is the lack of FIPS certification, which means it cannot be used!

      1. Mark R

        Exactly! The lack of FIPS 140 validation for 1.1.1 is keeping my company on OpenSSL 1.0.2. I’m sure that many others are in the same boat.


Leave a Reply

Your email address will not be published. Required fields are marked *