With the decrypting of a protected PayPal browser cookie at a security conference Friday, it became official: the internet's foundation of trust has suffered yet another serious fracture that will require the attention of the industry's best minds.
Within hours of the demonstration by researchers Juliano Rizzo and Thai Duong, Google researcher Adam Langley signaled his growing acceptance that secure sockets layer, the decade-old cryptographic standard that protects web addresses using the https prefix, was susceptible to an attack that previously was considered impractical. The result: by tampering with with an encryption algorithm's CBC – cipher block chaining – mode, hackers could secretly decrypt portions of the encrypted traffic.
“The CBC attacks were believed to be largely theoretical but, as Duong and Rizzo have pointed out today, that's no longer the case,” Langley wrote.
He went on say that, as previously reported, developers of Google's Chrome browser are experimenting with a work-around but are not yet sure if it will create incompatibilities with various websites. He also said Google SSL is highly resistant to the attack because it favors the RC4 cipher, which doesn't use CBC.
By Monday, both Microsoft and Mozilla acknowledged that their wares were also affected. An advisory issued by Redmond recommended that websites follow Google's lead to favor the RC4 cipher while Microsoft engineers develop a Windows update to patch the underlying weakness. Mozilla, meanwhile, made public a three-month old discussion of the underlying vulnerability and the best way to fix it without breaking huge numbers of websites.
To be fair, Duong and Rizzo's exploit isn't the easiest to pull off. Attackers must already control the network used by the intended victim, and they can only recover secret information that's transmitted repeatedly in a predictable location of the encrypted data stream. They must also have means to subvert a safety mechanism built into the web known as the same-origin policy, which dictates that data set by one domain name can't be read or modified by a different address.
To get around the SOP, the researchers used a Java applet, but they said there are other methods for achieving the same goal.
But as Duong and Rizzo showed, those constraints weren't enough to stop them from revealing the plaintext of an SSL-protected browser cookie transmitted with each request that a logged-in PayPal user makes on the payments website. Using what's presumed to be a super-fast connection somewhere in Mountain View, California, Duong was able to recover the authentication in about two minutes, giving him everything he needed to gain unauthorized access to someone else's account.
The researchers have published a post-presentation analysis and video here. For an excellent technical description of the attack, check out this analysis from Eric Rescorla. It's upshot is the mildly comforting conclusion that “no SSL/TLS is not completely broken.”
“As it stands, given the number of difficult conditions necessary for deploying this attack, as well as the dependency on leveraging a Java applet for violating SOP, it seems extremely unlikely that individual browser users will be personally affected by this vulnerability.”
Fair enough. But keep in mind, too, that BEAST, short for Browser Exploit Against SSL/TLS, isn't the only reason to question the adequacy of the cryptographic system the entire internet uses to prevent eavesdroppers from accessing your private accounts. And remember that a patch introduced by OpenSSL in 2002 to fix this very vulnerability was turned off because it introduced incompatibilities in software from Microsoft.
SSL encryption may have dodged a bullet for now, but as the recent DigiNotar debacle demonstrated, the system itself isn't immune to real-world attacks that have very real consequences for those who depend on it. ®