New Collision Attacks Against 3DES, Blowfish Allow for Cookie Decryption

Researchers have found a new way to recover and decrypt authentication cookies from 3DES and Blowfish protected traffic. In response, OpenSSL is expected to deprecate 3DES’ designation from high to medium.

RC4 apparently is no longer the lone pariah among smaller cryptographic ciphers. Already broken and set for deprecation by the major browser and technology makers, RC4 could shortly have company in Triple-DES (3DES) and Blowfish.

Researchers are set to present new attacks against 64-bit ciphers that allow for the recovery of authentication cookies from 3DES-protected traffic in HTTPS and the recovery of usernames and passwords from OpenVPN traffic, which is secured by default by Blowfish.

OpenSSL, meanwhile, was already scheduled to release 1.1.0 this week and coinciding with that release is the decision to remove 3DES from the 1.1.0 default build. It will also update the source code in its Git repository to reflect a drop of 3DES’ designation as a cipher from high to medium in 1.0.2 and 1.0.1; users will see this in a future release. Users will have configure 3DES at build-time in 1.1.0 to enable it. OpenVPN is also expected to release version 2.3.12 this week with a warning about Blowfish weaknesses and secure configuration advice.

Researchers Gaetan Leurent and Karthikeyan Bhargavan of Inria, France, will formally present their paper, “On the Practical (In-)Security of 64-Bit Ciphers” in October at the ACM Conference on Computer and Communications Security in Austria.

The attack, called SWEET32, is a collision attack against these ciphers in CBC mode, or cipher block chaining; 64-bit ciphers such as Blowfish and 3DES are still supported in TLS, IPsec, SSH and other protocols. The researchers said that 3DES support for HTTPS servers that show in Alexa’s top website list hovers between 1 percent and 2 percent of traffic on Firefox, Internet Explorer, Chrome and Android 5.0 integrated browser.

“The browsers are not killing 3DES; they’re waiting until there’s less use. Right now, 1 percent to 2 percent is a lot of traffic and they’re not comfortable with it,” Leurent told Threatpost.

While this is not a massive Internet-wide attack, Leurent said that developers and enterprises should treat it as they would the deprecation of RC4.

“It’s something to get rid of because it’s a security problem,” he said. “We don’t have very good security when we use 3DES.”

In July 2015, Belgian researchers published work that described a new attack against RC4 that hastened its deprecation. New biases in the cipher were discovered that allowed for the rapid recovery and decryption of cookies (inside of 72 hours) on sites running TLS with RC4 as well as WPA-TKIP. RC4 was much more widely deployed at the time and merited more immediate attention because of the Belgian attack. Their work was preceded by a 2013 attack developed by Daniel Bernstein of the University of Illinois, Chicago that was also a feasible attack against RC4 on a site protected by TLS.

Leurent’s attack uses a well-known means of targeting traffic protected by these smaller ciphers in order to retrieve the cookies and credentials, he said.

“When you encrypt lots of message blocks with the same key, at some point, you expect to have a collision with the inputs of the cipher and you can see a collision in the outputs of the cipher. When we detect this collision in the output, we know there had to be a collision in the input,” Leurent explained. “Because of way CBC mode works, when we have a collision on the input, this gives us the XOR of two message blocks. It’s a well-known attack on the CBC mode that if you encrypt too many blocks, at some point you have a collision. This gives you the XOR of two different message blocks.”

Building on this, an attacker can target a victim’s authentication cookie by luring them to a site they control where they can inject JavaScript into the user’s browser that will repeatedly send HTTP queries to whatever site the victim is logged into. Each request will include the authentication cookie for that site, and if the attacker is able to send at least 232 queries and capture all those requests, they’re bound to see a collision and eventually recover the session cookie.

“What makes it practical is 232 is a small number,” Leurent said, pointing out that AES and newer ciphers provide 128-bit security, double that of 3DES and Blowfish. “The first collision is expected after about 32 GB of data (an attacker needs several collisions to get the cookie.) Problems start to appear after 32 GB, and that’s not a lot of traffic. That’s well known to cryptographers, but seems to be less known on the more practical side of security.”

The simplest mitigation, Leurent said, is to stop using small block ciphers such as these and move to AES, for example. The implementation of shorter sessions before rekeying is also a good mitigation, he said, because that makes the attack more expensive. But it’s also more expensive to change keys more frequently, meaning there has to be a tradeoff at some point.

“The message is to try to get rid of legacy crypto that’s not that good,” Leurent said. “Even if attacks are not that practical, it’s good to get rid of them.”

Suggested articles