As mentioned in a previous blog post, OpenSSL team members met with various representatives of the FIPS sponsor organisations back in September last year to discuss design and planning for the new FIPS module development project.

Since then there has been much design work taking place and we are now able to publish the draft design documentation. You can read about how we see the longer term architecture of OpenSSL changing in the future here and you can read about our specific plans for OpenSSL 3.0 (our next release which will include a FIPS validated module) here.

20 years ago, on the 23rd December 1998, the first version of OpenSSL was released. OpenSSL was not the original name planned for the project but it was changed over just a few hours before the site went live. Let’s take a look at some of the early history of OpenSSL as some of the background has not been documented before.

The OpenSSL Management Committee has been looking at the versioning scheme that is currently in use. Over the years we’ve received plenty of feedback about the “uniqueness” of this scheme, and it does cause some confusion for some users. We would like to adopt a more typical version numbering approach.

The current versioning scheme has this format:

MAJOR.MINOR.FIX[PATCH]

The new scheme will have this format:

MAJOR.MINOR.PATCH

In practical terms our “letter” patch releases become patch numbers and “fix” is dropped from the concept. In future, API/ABI compatibility will only be guaranteed for the same MAJOR version number. Previously we guaranteed API/ABI compatibility across the same MAJOR.MINOR combination. This more closely aligns with the expectations of users who are familiar with semantic versioning. We are not at this stage directly adopting semantic versioning because it would mean changing our current LTS policies and practices.

The current 1.1.1 and 1.0.2 versioning scheme will remain unchanged.

The current development version (master branch) will be identified as version 3.0.0. The OpenSSL FIPS module currently under development will also follow this versioning scheme. We are skipping the 2.0.0 major version because the previous OpenSSL FIPS module has already used this number.

OpenSSL version 3.0.0 will be the first version that we release under the Apache License 2.0. We will not be applying the Apache License to earlier releases of OpenSSL.

The OpenSSL Management Committee (OMC) on behalf of the OpenSSL Project would like to formally express its thanks to the following organisations for agreeing to sponsor the next FIPS validation effort: Akamai Technologies, Blue Cedar, NetApp, Oracle, VMware.

Four weeks ago, the OpenSSL team gathered with many of the organisations sponsoring the next FIPS module for a face-to-face meeting in Brisbane, Australia.

We got a great deal accomplished during that week. Having most of the fips-sponsor organisations in the same location helps ensure that we are all on the same page for the decisions we need to make going forward.

After two years of work we are excited to be releasing our latest version today - OpenSSL 1.1.1. This is also our new Long Term Support (LTS) version and so we are committing to support it for at least five years.

OpenSSL 1.1.1 has been a huge team effort with nearly 5000 commits having been made from over 200 individual contributors since the release of OpenSSL 1.1.0. These statistics just illustrate the amazing vitality and diversity of the OpenSSL community. The contributions didn’t just come in the form of commits though. There has been a great deal of interest in this new version so thanks needs to be extended to the large number of users who have downloaded the beta releases to test them out and report bugs.

We first announced last year the OpenSSL Management Committee and separate Committers groups aimed at enabling greater involvement from the community.

We have now added a new OMC member and two new committers.

Back around the end of 2014 we posted our release strategy. This was the first time we defined support timelines for our releases, and added the concept of an LTS (long-term support) release. At our OMC meeting earlier this month, we picked our next LTS release. This post walks through that announcement, and tries to explain all the implications of it.

“That we remove “We strongly believe that the right to advance patches/info should not be based in any way on paid membership to some forum. You can not pay us to get security patches in advance.” from the security policy and Mark posts a blog entry to explain the change including that we have no current such service.”

At the OpenSSL Management Committee meeting earlier this month we passed the vote above to remove a section our security policy. Part of that vote was that I would write this blog post to explain why we made this change.

At each face to face meeting we aim to ensure that our policies still match the view of the current membership committee at that time, and will vote to change those that don’t.

Prior to 2018 our Security Policy used to contain a lot of background information on why we selected the policy we did, justifying it and adding lots of explanatory detail. We included details of things we’d tried before and things that worked and didn’t work to arrive at our conclusion. At our face to face meeting in London at the end of 2017 we decided to remove a lot of the background information and stick to explaining the policy simply and concisely. I split out what were the guiding principles from the policy into their own list.

OpenSSL has some full-time fellows who are paid from various revenue sources coming into OpenSSL including sponsorship and support contracts. We’ve discussed having the option in the future to allow us to share patches for security issues in advance to these support contract customers. We already share serious issues a little in advance with some OS vendors (and this is still a principle in the policy to do so), and this policy has helped ensure that the patches and advisory get an extra level of testing before being released.

Thankfully there are relatively few serious issues in OpenSSL these days; the last worse than Moderate severity being in February 2017.

In the vote text we wrote that we have “no current such service” and neither do we have any plan right now to create such a service. But we allow ourselves to consider such a possibility in the future now that this principle, which no longer represents the view of the OMC, is removed.

The following is a press release that we just put out about how finishing off our relicensing effort. For the impatient, please see https://license.openssl.org/trying-to-find to help us find the last people; we want to change the license with our next release, which is currently in Alpha, and tentatively set for May.

For background, you can see all posts in the license category.

One copy of the press release is at https://www.prnewswire.com/news-releases/openssl-seeking-last-group-of-contributors-300607162.html.

Note: This is an outdated version of this blog post. This information is now maintained in a wiki page. See here for the latest version.

The forthcoming OpenSSL 1.1.1 release will include support for TLSv1.3. The new release will be binary and API compatible with OpenSSL 1.1.0. In theory, if your application supports OpenSSL 1.1.0, then all you need to do to upgrade is to drop in the new version of OpenSSL when it becomes available and you will automatically start being able to use TLSv1.3. However there are some issues that application developers and deployers need to be aware of. In this blog post I am going to cover some of those things.