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