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.
We just went live with a new website. The design is based on the style
included with Octopress; the new logo and some other
important CSS tweaks were contributed by Tony Arcieri.
The style is also mobile-friendly, so you can take us with you wherever
you go. :) We still need a better “favicon.”
The text still needs more work. As someone on the team pointed out,
“a worldwide community of volunteers that use the Internet to communicate,
plan, and develop [OpenSSL]” … really?
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.
The OpenSSL source doesn’t look the same as it did a year ago. Matt
posted about the big code reformatting. In this post I want review some
of the other changes – these rarely affect features, but are more than
involved than “just” whitespace.
Today, news broke of Logjam, an attack on TLS connections using Diffie-Hellman ciphersuites. To protect OpenSSL-based clients, we’re increasing the minimum accepted DH key size to 768 bits immediately in the next release, and to 1024 bits soon after. We have also made several other changes to strengthen our cryptographic defaults and have updated our tools and documentation to help servers configure Diffie-Hellman ciphersuites securely - see below for details.
We’ve just released security updates to OpenSSL 0.9.8, 1.0.0,
1.0.1, and 1.0.2.
These updates fix a number of Moderate and Low severity security
issues in OpenSSL. They also fix one new High severity issue,
CVE-2015-0291, that affects just OpenSSL 1.0.2, released in January
this year. A remote attacker could use this flaw to cause unfixed
servers to crash, which could lead to a denial of service attack
depending on the server.
At the end of January we completed the OpenSSL code reformat as previously mentioned here and here. This post is intended to give you a bit more insight into exactly what we’ve done.
We have previously announced our intention to reformat the entire
codebase into a more consistent style (see our roadmap document here:
https://www.openssl.org/policies/roadmap.html)