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
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
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.
I’m pleased to announce that white knight has arrived; SafeLogic has
committed to sponsor a new FIPS validation on
“truly open or bust” terms that address the major risks
that have prevented us from proceeding to date. SafeLogic is not only providing the critical funding
for this effort; they will also play a significant role. The co-founders of SafeLogic, Ray Potter and
Wes Higaki, wrote a book
about the FIPS 140 validation process. The SafeLogic technical lead will be Mark Minnoch, who
I worked with extensively when he was director of the accredited test lab
that performed the open source based validations for the OpenSSL FIPS Object Module 2.0. The
test lab for this effort will be Acumen Security. While I’ve not
worked directly with Acumen before, I have corresponded with its director and co-founder, Ashit
Vora, on several occasions and I know SafeLogic has chosen carefully.
With my OpenSSL colleagues doing the coding as before, in particular Steve Henson and Andy Polyakov, we have a
“dream team” for this sixth validation effort.
Note that this validation sponsorship is very unusual, and something most commercial companies would
be completely incapable of even considering. SafeLogic is making a bold move, trusting in us and in the
sometimes fickle and unpredictable FIPS validation process. Under the terms of this sponsorship OpenSSL
retains full control and ownership of the FIPS module software and the validation. This is also an
all-or-nothing proposition; no one – including SafeLogic – gets to use the new FIPS module until
and if a new open source based validation is available for everyone. SafeLogic is making a major contribution
to the entire OpenSSL user community, for which they have my profound gratitude.
Now, why would a commercial vendor like SafeLogic agree to such an apparently one sided deal? Your typical
MBA would choke at the mere thought. But, SafeLogic has thought it through carefully; they “get”
open source and they are already proficient at leveraging open source. This new OpenSSL FIPS module will
become the basis of many new derivative
products, even more so than the wildly popular 2.0 module, and no vendor is going to be closer to the action
or more familiar with the nuances than SafeLogic. As an open source product the OpenSSL FIPS module with
its business-friendly license will always be available to anyone for use in pursuing their own
validation actions, but few vendors have much interest in pursuing such a specialized and treacherous
process when better alternatives are available. Having sponsored and actively collaborated with the
validation from the starting line, SafeLogic will be in the perfect position to be that
There are a lot of moving parts to this plan – technical details of the new module, interim licensing, schedule
aspirations, etc. – that I’ll try to cover in upcoming posts.
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
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
Background on DROWN
DROWN research combines brute-force decryption of deliberately
weakened EXPORT-grade ciphersuites with a
Bleichenbacher padding oracle
exposed by an SSLv2 server to uncover TLS session keys. Bleichenbacher oracle
attacks are well known and defended-against but, ironically, the attack relies
on exactly these widely implemented countermeasures to succeed.
The original Bleichenbacher attack, while mathematically brilliant, is
still relatively infeasible to carry out in practice, requiring the
attacker to make hundreds of thousands to millions of connections to
the victim server in order to compromise a single session key. This is where the research
truly shines: beautiful mathematical techniques reduce the number of
connections to the ten thousands, bringing the attack down to a practical
level. The researchers spent a mere US$440 on the EC2 cloud platform to
decrypt a victim client session in a matter of hours.
The attack works against every known SSL/TLS implementation supporting
SSLv2. It is, however, particularly dangerous against OpenSSL versions
predating March 2015 (more on that below). Bottom line: if you are
running OpenSSL 1.0.2 (the first, no-letter release) or OpenSSL 1.0.1l
or earlier, you should upgrade immediately.
The DROWN attack is nuanced and non-trivial to implement, so we will
likely not see immediate exploitation. But, once implemented, the
effects are chilling. DROWN attackers can decrypt sessions recorded in
the past. All client sessions are vulnerable if the target server
still supports SSLv2 today, irrespective of whether the client ever
supported it. There is, however, a silver lining. Only plain RSA
handshakes are directly vulnerable - forward-secure sessions can
perhaps be compromised by a powerful man-in-the-middle attacker, but
all passively recorded forward-secure sessions remain secure.
Two devastating practical findings make DROWN much more impactful than
it ever should have been. First, it is surprisingly common for
services to share keys. DROWN can target your HTTPS server even if only
your email server supports SSLv2, so long as the two share the same
private key. While 11% of HTTPS servers with browser-trusted
certificates are directly vulnerable to DROWN, another whopping 11%
fall victim through some other service (most commonly SMTP on port
Second, in the OpenSSL security releases of March 2015, we rewrote
a section of code, which coincidentally
fixed a security bug (CVE-2016-0703). This bug, if present in the
server, makes the DROWN attack run in just a few minutes on, well, our
laptops. This reduced complexity could lead to successful real-time
man-in-the-middle attacks, hijacking a session even if the client and
the server would otherwise negotiate a forward-secure Diffie-Hellman
ciphersuite. Much to our surprise, DROWN scans found over 4 million
HTTPS servers that, almost a year later, are still unpatched. In the
wake of Heartbleed, the world saw a surge of upgrades but the
awareness appears to have dropped. Thus, while the following FAQ will
guide you through defending your services against DROWN, we encourage
you to upgrade to OpenSSL latest even if you’re not vulnerable, and
keep doing so regularly upon every security release.
DROWN FAQ for OpenSSL users
Is my server vulnerable to DROWN?
It depends on your server configuration. You can only be sure that you
are not vulnerable if none of your services sharing a given private
key enable SSLv2. Your secure TLS-only HTTPS server is vulnerable if you
expose the same key on an email server that supports SSLv2.
Apache HTTP Server users
If you use an Apache HTTP server with keys that you don’t
share with any other services, and
that server runs Apache httpd 2.4.x, you are not affected (because httpd 2.4
unconditionally disabled SSLv2). If the server runs Apache httpd 2.2.x,
SSLv2 is supported by default, and you are likely to be
vulnerable. You should ensure that your
configuration disables SSLv2
(and preferably, SSLv3 too):
Later nginx versions have safe default configurations, but you should
double-check the ssl_protocols setting in your config.
Postfix releases 2.9.14, 2.10.8, 2.11.6, 3.0.2,
released on 20/Jul/2015 and all later releases are not vulnerable
in their default configuration. The below recommended TLS settings
for Postfix are sufficient to avoid exposure to DROWN. Many of these
are defaults in sufficiently recent releases. Nevertheless, in addition
to ensuring that your Postfix configuration disables SSLv2 and weak or
obsolete ciphers, you should also deploy the appropriate OpenSSL upgrade.
# Minimal recommended settings. Whenever the built-in defaults are
# sufficient, let the built-in defaults stand by deleting any explicit
# overrides. The default mandatory TLS protocols have never included
# SSLv2, check to make sure you have not inadvertently enabled it.
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
tlsproxy_tls_protocols = $smtpd_tls_protocols
tlsproxy_tls_mandatory_protocols = $smtpd_tls_mandatory_protocols
smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3
lmtp_tls_protocols = !SSLv2, !SSLv3
lmtp_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_ciphers = medium
smtp_tls_ciphers = medium
# Other best practices
# Strongly recommended:
smtpd_tls_eecdh_grade = strong
# Suggested, not strictly needed:
EXPORT, LOW, MD5, SEED, IDEA, RC2
EXPORT, LOW, MD5, aDSS, kECDHe, kECDHr, kDHd, kDHr, SEED, IDEA, RC2
Note that if you’re running anything but the latest OpenSSL releases
from January 2016 (1.0.2f and 1.0.1r), a subtle bug
(CVE-2015-3197) allows the server to accept SSLv2 EXPORT handshakes
even if EXPORT ciphers are not configured. Therefore, disabling weak
ciphers is not a universally reliable countermeasure against DROWN;
you should really disable SSLv2 entirely.
In short: yes, everyone should upgrade. You can mitigate DROWN
completely with a configuration change. But today’s release fixes a
number of other vulnerabilities, and we cannot emphasize the
importance of timely upgrades enough.
How do I know which OpenSSL version my system is running?
If you are using the system OpenSSL provided with your Linux
distribution, or obtained OpenSSL from another vendor, the version
number is not a reliable indicator of the security status. Some third
party distributions have a policy of only backporting selected
security updates without changing to a newer version, to provide
stability. Each distribution varies; you should install the updates provided by
your vendor and contact them for questions about this or any other
I run an OpenSSL-based client application. Do I need to do anything?
DROWN is primarily a server-side vulnerability. However, as a matter
of best practices, you should ensure that your client supports the
highest current protocol version (TLSv1.2), and negotiates
You should also upgrade to OpenSSL latest. (Did we say that already?)
Does DROWN compromise my private key?
No. DROWN attacks can only target individual sessions, not the
server’s key. Even if there has been a successful DROWN attack against
you, there is no need to regenerate your private key, so long as you can
confidently identify all services that share this key, and disable
SSLv2 for them.
The OpenSSL team would like to thank Nimrod Aviram, J. Alex Halderman
and the entire DROWN team for their cooperation.
For the longest time, it seems that people have wanted to have their
diverse engines bundled with the OpenSSL source, as if there was no
other way to build it or distribute it.
Nothing could be further from the truth. Also, having the engine for
some hardware bundled with the OpenSSL source presents a maintainance
problem, and the better solution is for those who have an engine to
maintain theḿ themselves.
So, how is it done? That’s something that we will discover together
in a series of articles, about one or two weeks apart.
First lesson up, warming up with a minimal, silly and utterly useless
At all times, feel free to comment, to make suggestions, ask for
specific future lessons, and so on and so forth.