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.
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.
We’ve just added a new severity level called “critical severity” to our
security policy. When we first introduced the policy, over a year ago, we just
had three levels, “Low”, “Moderate”, and “High”. So why did we add “Critical” and
why are we not using someone else’s standard definitions?
After introducing the new policy we started giving everyone a headsup when we
were due to release OpenSSL updates that included security fixes. The headsup
doesn’t contain any details of the issues being fixed apart from the maximum
severity level and a date a few days in the future.
Some of you may have noticed that the upcoming 1.1 release doesn’t include any FIPS support. That omission is not by choice; it was forced on us by circumstances and will hopefully not be permanent.
The v2.0 OpenSSL FIPS module is compatible with the 1.0.x releases, in particular the 1.0.2 “LTS” release that will be supported through 2019. It has proven very popular, used both directly by hundreds of software vendors and indirectly as a model for copycat “private label” validations.
Over the last 10 years, OpenSSL has published advisories on over 100 vulnerabilities. Many more were likely silently fixed in the early days, but in the past year our goal has been to establish a clear public record.
In September 2014, the team adopted a security policy that defines how we handle vulnerability reports. One year later, I’m very happy to conclude that our policy is enforced, and working well.
Our policy divides vulnerabilities into three categories, and defines actions for each category: we use the severity ranking to balance the need to get the fix out fast with the burden release upgrades put on our consumers.
The OpenSSL license is rather unique and idiosyncratic. It reflects
views from when its predecessor, SSLeay, started twenty years ago. As a
further complication, the original authors were hired by RSA in 1998,
and the code forked into two versions: OpenSSL and RSA BSAFE SSL-C.
(See Wikipedia for discussion.) I don’t
want get into any specific details, and I certainly don’t know them all.
Things have evolved since then, and open source is an important part of
the landscape – the Internet could not exist without it.
There are good reasons why Microsoft is a founding member of the
Core Infrastructure Initiative (CII).
Our plan is to update the license to the
Apache License version 2.0.
We are in
consultation with various corporate partners, the CII, and the legal experts
at the Software Freedom Law Center.
In other words, we have a great deal of expertise and interest at our
fingertips.