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.
The following is a press release that we just released, with the cooperation and financial support of the Core Infrastructure Initiative and the Linux Foundation.
In the next few days we’ll start sending out email to all contributors asking them to approve the change. In the meantime, you can visit the licensing website and search for your name and request the email. If you have changed email addresses, or want to raise other issues about the license change, please email firstname.lastname@example.org. You can also post general issues to email@example.com.
We are grateful to all the contributors who have contributed to OpenSSL and look forward to their help and support in this effort.
The official press release can be found at the CII website. The rest of this post is a copy:
This post talks about OpenSSL and threads. In particular, using OpenSSL in multi-threaded applications. It traces through the history, explains what was changed for the 1.1.0 release, and will hopefully provide some guidance to developers.
While none of the behaviors have really changed, and therefore none of this should be new information, the documentation has not been as clear as it could, or should, be. Therefore, some readers might be surprised by what’s in this post.
In short, OpenSSL has always, and only, supported the concept of locking an object and sometimes it locks its internal objects. Read on for more details.
Last October, the OpenSSL Project team had a face to face meeting. We talked about many topics but one of them was that, in recent years, we have seen much more involvement from the community and that we would like to encourage that further. For example, there are a number of people in the community who we know and trust. We would like those people to get involved more and make it easier for them to contribute. We decided to introduce the concept of a “committer” (borrowed from the Apache concept): someone who has the ability to commit code to our source code repository but without necessarily having to become a full team member. This might be seen as a stepping-stone for someone who aspires to full team membership, or simply as an easier way of contributing for those that don’t. Those people could help with our review process (i.e., their reviews would count towards approval) - which might help us keep on top of the github issues and pull request queues.
This is another in the series of posts about decisions we made at our face-to-face meeting a couple of weeks ago.
We updated the project roadmap.
I think the most important news here, is that our next release will include TLS 1.3. Our current plan is that this will be 1.1.1, which means that it is API-compatible with the current 1.1.0 release. This is really only possible because of the work we did on making most of the structure internals opaque. Also, since we are doing all of our work in public on our GitHub repository, we hope that the entire community will be able to “follow along at home” and help us improve the code. There will be more, much more, to say about this later.
We have also set ourselves major goals of increasing our code coverage and protocol-level testing. In addition, all new API’s must be documented, and the entire set of SSL API’s will also be documented. The script util/find-undoc-api.pl lists them. If you’re inclined to help write some documentation, please feel free!
There are a variety of other crypto-nerd things we are looking at, so please see the roadmap for details.
The second point I want to mention in this post is that we have sketched out a platform policy. This is, admittedly, an overdue item from our first meeting two years ago. The first step will be to review all targets in the configuration scripts, and classify them according to the categories mentioned in the platform policy by our next release.
Which, in case I failed to mention it, will include TLS 1.3 :)
Last week, the OpenSSL dev team had another face-to-face meeting. It was a week of “mosts”: most of the team flew in for most of the week, and most of it was funded by the CII/LF
We got a great deal accomplished during that week. We do many things by vote, and having everyone in the room to talk not only beats email all to hell, but it ensures that we’re all on the same page for the decisions we make. Sure, not everything was a unanimous decision, but none were decided by narrow margins.
In this post I’m going to talk about two important decisions.
Today, Karthik Bhargavan and Gaetan Leurent from Inria have unveiled a new attack on Triple-DES, SWEET32, Birthday attacks on 64-bit block ciphers in TLS and OpenVPN. It has been assigned CVE-2016-2183.
This post gives a bit of background and describes what OpenSSL is doing. For more details, see their website.
The last post on this topic sounded a skeptical note on the prospects for a new FIPS 140 validated module for OpenSSL 1.1 and beyond. That post noted a rather improbable set of prerequisites for a new validation attempt; ones I thought only a governmental sponsor could meet (as was the case for the five previous open source based validations).
Multiple commercial vendors have offered to fund (very generously in some cases) a new validation effort under terms that would guarantee them a proprietary validation, while not guaranteeing an open source based validation. At one point we actually came close to closing a deal that would have funded an open source based validation attempt in exchange for a limited period of exclusivity; a reasonable trade-off in my opinion. But, I eventually concluded that was too risky given an uncertain reception by the FIPS validation bureaucracy, and we decided to wait for a “white knight” sponsor that might never materialize.
In commits a004e72b9 (1.0.2) and 6f35f6deb (1.0.1) we released a fix for CVE-2016-2177. The fix corrects a common coding idiom present in OpenSSL 1.0.2 and OpenSSL 1.0.1 which actually relies on a usage of pointer arithmetic that is undefined in the C specification. The problem does not exist in master (OpenSSL 1.1.0) which refactored this code some while ago. This usage could give rise to a low severity security issue in certain unusual scenarios. The OpenSSL security policy (https://www.openssl.org/policies/secpolicy.html) states that we publish low severity issues directly to our public repository, and they get rolled up into the next release whenever that happens. The rest of this blog post describes the problem in a little more detail, explains the scenarios where a security issue could arise and why this issue has been rated as low severity.
Today, an international group of researchers unveiled DROWN (Decrypting RSA with Obsolete and Weakened eNcryption), aka CVE-2016-0800, a novel cross-protocol attack that uses SSLv2 handshakes to decrypt TLS sessions.
Over the past weeks, the OpenSSL team worked closely with the researchers to determine the exact impact of DROWN on OpenSSL and devise countermeasures to protect our users. Today’s OpenSSL release makes it impossible to configure a TLS server in such a way that it is vulnerable to DROWN.