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.
The audit took place during 2015 in two phases while the OpenSSL project was
working on the development of the (now released) 1.1.0 version. We chose to
audit the “master” branch of the code as it stood at the time. OpenSSL 1.1.0 has
made some extensive internal changes, most notably in libssl with the new
state machine code, as well as the new packet parsing code. We wanted the audit
team to review that code to give us confidence that what we were delivering was
sound.
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.
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://openssl-library.org/policies/general/security-policy/) 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.