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.

Because DES (and triple-DES) has only a 64-bit block size, birthday attacks are a real concern. With the ability to run Javascript in a browser, it is possible to send enough traffic to cause a collision, and then use that information to recover something like a session Cookie. Their experiments have been able to recover a cookie in under two days. More details are available at their website. But the take-away is this: triple-DES should now be considered as “bad” as RC4.

Triple-DES, which shows up as “DES-CBC3” in an OpenSSL cipher string, is still used on the Web, and major browsers are not yet willing to completely disable it.

If you run a server, you should disable triple-DES. This is generally a configuration issue. If you run an old server that doesn’t support any better ciphers than DES or RC4, you should upgrade.

Within the OpenSSL team, we discussed how to classify this, using our security policy, and we decided to rate it LOW. This means that we just pushed the fix into our repositories. Here is what we did:

• For 1.0.2 and 1.0.1, we removed the triple-DES ciphers from the “HIGH” keyword and put them into “MEDIUM.” Note that we did not remove them from the “DEFAULT” keyword.

• For the 1.1.0 release, which we expect to release tomorrow, we will treat triple-DES just like we are treating RC4. It is not compiled by default; you have to use “enable-weak-ssl-ciphers” as a config option. Even when those ciphers are compiled, triple-DES is only in the “MEDIUM” keyword. In addition, because this is a new release, we also removed it from the “DEFAULT” keyword.

When you have a large installed base, it is hard to move forward in a way that will please everyone. Leaving triple-DES in “DEFAULT” for 1.0.x and removing it from 1.1.0 is admittedly a compromise. We hope the changes above make sense, and even if you disagree and you run a server, you can explicitly protect your users through configuration.

Finally, we would like to thank Karthik and Gaeten for reaching out to us, and working closely to coordinate our releases with their disclosure.