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.

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 better alternative.

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 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.

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 25).

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):

1

SSLProtocol All -SSLv2 -SSLv3

nginx users

Versions 0.7.64, 0.8.18, and earlier enable SSLv2 by default. You should similarly disable SSLv2 in your configuration:

1

ssl_protocols TLSv1 TLSv1.1 TLSv1.2

Later nginx versions have safe default configurations, but you should double-check the ssl_protocols setting in your config.

Postfix users

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.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

   # 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:
   # http://www.postfix.org/FORWARD_SECRECY_README.html#server_fs
   #
   smtpd_tls_dh1024_param_file=${config_directory}/dh2048.pem
   smtpd_tls_eecdh_grade = strong

   # Suggested, not strictly needed:
   #
   smtpd_tls_exclude_ciphers =
        EXPORT, LOW, MD5, SEED, IDEA, RC2
   smtp_tls_exclude_ciphers =
        EXPORT, LOW, MD5, aDSS, kECDHe, kECDHr, kDHd, kDHr, SEED, IDEA, RC2

Everyone

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.

The DROWN researchers have also set up a more precise test for vulnerable services.

Should I upgrade to the latest OpenSSL version?

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 obtained OpenSSL directly from us (from https://www.openssl.org, or from https://github.com/openssl/openssl), run the following command to find out:

1

$ openssl version

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 security issues.

Debian users can also track the security status of Debian releases, using Debian’s security tracker. All issues affecting OpenSSL can be found in the search by source package and information about DROWN will appear under the tracker for CVE-2016-0800.

Red Hat has an information page about this issue for their users.

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 forward-secure ciphersuites.

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.

Coming back after a month and two weeks, it’s time to resume with the next engine lesson, this time building an engine implementing a digest.

It doesn’t matter much what digest algorithm we choose. Being lazy, I’ve chosen one with a well defined reference implementation, MD5 (reference implementation is found in RFC 1321)

In this lesson, we’re going to explore minimalism, in this case in the form of the most minimal engine possible (without obfuscating it).

The least boilerplate code for an engine looks like this:

1
2
3
4

#include <openssl/engine.h>

IMPLEMENT_DYNAMIC_BIND_FN(bind)
IMPLEMENT_DYNAMIC_CHECK_FN()

This example isn’t complete, it will not compile. However, it contains the absolute minimum required for those module to even be recognised as an OpenSSL engine.

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 engine!

At all times, feel free to comment, to make suggestions, ask for specific future lessons, and so on and so forth.