We have previously talked about our plans for OpenSSL 3.0 and FIPS support here. This blog post will give an update about what has been happening since then.

There has been a huge amount of development effort that has gone into the new OpenSSL 3.0 version. As of the time of writing there have been 2112 commits made to the master branch of git (where all the new development work takes place) since the release of OpenSSL 1.1.1 back in September 2018, and that number is going up every day. To give an idea of the scale of these changes that represents 8.5% of all the commits ever made to OpenSSL since it was founded back in 1998!

OpenSSL 3.0 represents a major re-architecture of the internal plumbing of OpenSSL. We’ve been talking about this for a while and you can read a detailed description of the planned changes in our design document.

The biggest single change is the introduction of a concept called “Providers”. In OpenSSL 3.0 all cryptographic algorithms will be implemented in a provider. There will be a “default” built-in provider, as well as others such as a “legacy” provider to enable access to legacy algorithms and a “FIPS” provider to enable access to FIPS validated algorithms.

There has been significant progress towards implementing the changes in that design document. The three providers I described above are already present and (almost) all ciphers and digests have been migrated into them as well as numerous other algorithms. Migration of the various asymmetric algorithms is currently in progress. For those interested in following the current active development you can look at the currently active pull requests here.

Our original timeline had us aiming to be code complete by the end of this year (2019), after which we would do a series of beta releases in parallel with the FIPS lab doing its work. The final release of 3.0 was expected in early Q2 2020 with the actual validation of the FIPS module occurring sometime after that.

In spite of the extensive progress made there is still much left to do. It has become clear that we will not be able to achieve those original timeline aspirations. We are now not expecting code completion to occur until the end of Q2 2020 with a final release in early Q4 2020.

We still expect the upgrade path from OpenSSL 1.1.1 to OpenSSL 3.0 to be relatively easy for most applications. In most cases applications will simply need to recompile in order to work with the new version. However, some changes may be required in order to benefit from the new features being introduced in OpenSSL 3.0 - for example to use algorithms from one of the new providers. In the simplest cases these changes might just be configuration file updates. In other cases code changes will be required.

The changes required for existing users of OpenSSL 1.0.2 to upgrade to OpenSSL 3.0 are more significant. For existing users of OpenSSL 1.0.2 we recommend upgrading to our newest LTS (Long Term Support) release 1.1.1, in order to ease the future migration to OpenSSL 3.0.

Note that as previously announced OpenSSL 1.0.2 will be End Of Life at the end of this year. This means there will not be any further public updates or security fixes to the 1.0.2 branch from then. This gives another strong reason for existing 1.0.2 users to upgrade to 1.1.1 as soon as possible.

Users of the old FIPS Object Module (OpenSSL FOM 2.0) are not able to use that with OpenSSL 1.1.1 (it only works with OpenSSL 1.0.2). We are expecting no further updates to the FOM 2.0 and it has not been receiving any fixes for some time. There was always expected to be a gap between the EOL of OpenSSL 1.0.2 and OpenSSL 3.0. Unfortunately with the new expected delivery dates for OpenSSL 3.0 the gap has got bigger. Users of the OpenSSL FOM 2.0 should plan their response to that gap. One option is to take out a premium support contract which will continue to offer security fixes for the 1.0.2 branch (although not the FOM) for the foreseeable future. You can contact us at osf-contact@openssl.org for further details on that option.

In summary there has been much development activity over the last year and much remains to be done. I’d encourage anyone who wants to help out to start looking at our github pages. A good place to start is the list of issues. We are always keen to see newcomers proposing fixes for those issues. If you want to take a sneek peek at the new code then just download the latest code from the master git branch and have a go with it. We’d be particularly keen to hear about any issues that you might encounter.