SSL Labs DROWN test implementation details

Two days ago the DROWN vulnerability came to light, showing new ways to attack TLS. SSL Labs deployed tests for DROWN in the staging environment yesterday, and we’ll be pushing it to production shortly. Because DROWN is a tricky problem, the aim of this blog post is to provide an explanation of what we test for and how exactly.

First of all, we have known SSL v2 to be insecure for a very long time—over 20 years. As a result, even before DROWN SSL Labs used to give Fs to servers that supported this ancient version of the SSL protocol. DROWN actually makes things worse, because it abuses SSL v2 to attack all other protocols, but we don’t have a worse grade, so F will have to do.

Further, DROWN introduces two additional attack vectors:

• A server that has SSL v2 enabled can be used to attack any other servers that reuse the same RSA key; even those servers that don’t themselves support SSL v2. This attack is generic (CVE-2016-0800) and affects any protocol implementation.
• A server that has SSL v2 enabled and is also running a special vulnerable version of OpenSSL (CVE-2016-0703) can be used to attack all other hostnames appear in its certificate.

For the above reasons, the security of a server can’t be determined only by looking at its configuration. For DROWN, we have to look for the presence of the server’s RSA keys and/or certificate hostnames elsewhere. As you can imagine, this can be tricky. However, this is where the DROWN authors and Censys come in: they have exposed an API that SSL Labs now uses to find vulnerable servers in their data set.

Because the data we’re getting from Censys can be potentially stale, in SSL Labs we perform real-time checks for any of the above conditions. If we can find one matching server elsewhere, we consider the server being tested to be vulnerable and give it an F. Please note that the first 4 columns of the results (IP Address, Port, Export and Special) come from the search engine and could be outdated. The last column (Status) comes from SSL Labs; it reflects the current situation.

One final thing: if you’re manually checking the SSL Labs results, please don’t get confused if you’re unable to connect to a host using SSL v2. If SSL Labs is still showing the host as vulnerable, chances are it’s using a version of OpenSSL that can complete a handshake even when no cipher suites are configured (CVE-2015-3197). SSL Labs checks for this variant as part of its testing.

Tags