OpenSSL Provides Another Reminder to Disable SSLv2 (and 3, while you’re at it)

Open source software is great — we use tons of it at Duo — but recent news has challenged the idea that public scrutiny will result in software without serious vulnerabilities.

Overview

Yes, there's another newly discovered bug in OpenSSL, announced last week as the highest priority, the patches for which went public today as OpenSSL versions 1.0.2g and 1.0.1s. 33% of HTTPS servers on the Internet are vulnerable. Go patch now!

This time, the bug, named "DROWN", produces what's known in cryptography as an "oracle": something that leaks bits of information that should really be kept secret. In this case, it is possible that information leaked by OpenSSL's SSLv2 implementation can be used to decrypt other connections, even if they use safe, modern encryption.

This can pose real risk to organizations. For instance, if your email server was vulnerable to this bug, an employee accessing e-mail at a coffee shop would be susceptible to several things: an attacker could spy on their email conversations or steal their credentials.

Mitigation

This underscores the importance of using modern encryption protocols and ensuring that your servers aren't susceptible to degradation to insecure standards. There are many tools, for example Qualys SSL Labs, that can tell you if your HTTPS servers can be convinced to use older encryption standards like SSLv2.

We’ve known not to use SSLv2 for a while; it was deprecated in 2011 but that was just the official nail in the coffin. Crypto heroes Bruce Schneier and Dave Wagner noted SSLv2 as being full of “gaping holes” as early as 1997. Even its immediate successor, SSLv3, has been considered unsafe for over a year now.

Duo recommends that you don’t use SSLv2 at all, if possible. Your best mitigation is to disable deprecated protocols entirely. Mozilla has also made a nice tool for generating locked-down web server configurations.

If you think you need SSLv2, for example when dealing with legacy devices without updated libraries, supporting modern cryptographic standards, you need to patch your OpenSSL installation immediately. If you're interested in more background, Matt Green has an excellent write-up.

Testing

We've been focusing on web servers here but there are other scenarios where transport-layer encryption that could include OpenSSL is present, for example mail servers and database servers. In these cases, your easiest option for assessing protocol support is by attempting to connect to them. This can be done easily with the OpenSSL command-line tools:

openssl s_client -connect yourorg.net:3306 -ssl2

After attempting to negotiate the connection, you will either see an error (indicating that the protocol is likely disabled):

CONNECTED(00000003)
2734723140:error:1407F0E5:SSL routines:SSL2_WRITE:ssl handshake failure:s2_pkt.c:429:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 48 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : SSLv2
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1456772793
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

If SSLv2 is enabled, you will see a complete handshake with more data transferred and a cipher suite selected:

CONNECTED(00000003)
---
Server certificate
-----BEGIN CERTIFICATE-----
redacted
-----END CERTIFICATE-----
subject=redacted
issuer=redacted
---
No client certificate CA names sent
---
Ciphers common between both SSL endpoints:
RC4-MD5         RC2-CBC-MD5     DES-CBC3-MD5
---
SSL handshake has read 1239 bytes and written 367 bytes
---
New, SSLv2, Cipher is RC2-CBC-MD5
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : SSLv2
    Cipher    : RC2-CBC-MD5
    Session-ID: A79733E17D1614C67BE7CF032E53EDA3
    Session-ID-ctx:
    Master-Key: 753E74E79290C5C70EC0F11BE721CD6D
    Key-Arg   : 54634093A5F41AF4
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1456773891
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

The team that found and measured the bug also made a logo a tool to check for the vulnerability (about halfway down the page), if the server you care about is exposed to the public Internet.

So What?

Have we mentioned that you should update? Go do that now. Pretty please?

System administrators ought to have disabled all support for SSLv2 (and SSLv3!) years ago, given the weaknesses and attacks that we've seen throughout the past 5+ years. And, yet, 25% of the Alexa top 1m sites are willing to talk SSLv2, rendering useless the responsibly chosen modern crypto options of well-behaved clients. Additionally, a scan of the entire internet found around 6 million hosts supporting SSLv2. This makes pandas everywhere sad, since this state of affairs was totally avoidable. More broadly, this demonstrates the need for sysadmins of secure systems to stay up to date with which security options are considered best practices by the crypto/security nerds. Failure to do so is negligent.