SSL broken, again, in POODLE attack

From the researchers that brought you BEAST and CRIME comes another attack against Secure Sockets Layer (SSL), one of the protocols that's used to secure Internet traffic from eavesdroppers both government and criminal.

Calling the new attack POODLE—that's "Padding Oracle On Downgraded Legacy Encryption"—the attack allows a man-in-the-middle, such as a malicious Wi-Fi hotspot or a compromised ISP, to extract data from secure HTTP connections. This in turn could let that attacker do things such as access online banking or e-mail systems. The flaw was documented by Bodo Möller, Thai Duong, and Krzysztof Kotowicz, all of whom work at Google. Thai Duong, working with Juliano Rizzo, described the similar BEAST attack in 2011 and the CRIME attack in 2012.

The attack depends on the fact that most Web servers and Web browsers allow the use of the ancient SSL version 3 protocol to secure their communications. Although SSL has been superseded by Transport Layer Security, it's still widely supported on both servers and clients alike and is still required for compatibility with Internet Explorer 6. SSLv3, unlike TLS 1.0 or newer, omits validation of certain pieces of data that accompany each message. Attackers can use this weakness to decipher an individual byte and time of the encrypted data, and in so doing, extract the plain text of the message byte by byte.

As with previous attacks of this kind against SSL, the most vulnerable application is HTTP. An example attack scenario would work something like this. An adversary (typically in cryptography literature known as Mallory) sets up a malicious Wi-Fi hotspot. That Wi-Fi hotspot does two things. On non-secure HTTP connections, it injects a piece of JavaScript. And on secure HTTP connections, it intercepts the outgoing messages and reorganizes them.

Mallory's goal is to retrieve the HTTP session cookie used by some domain of interest, such as a Web mail service; with this session cookie, Mallory can access the mail service while masquerading as her victim. Mallory's injected JavaScript tells the browser to repeatedly try to load an image from that Web mail. Each image request will carry with it the session cookie, and the JavaScript ensures that each of these requests is constructed in such a way as to ensure that the one byte of the session cookie is placed in a particular place within each SSL message.

The malicious router will then reorganize the SSL message, copying the portion with the session cookie to the end of the message. Most of the time, this will result in the data being garbled when the server tries to decrypt it, and the connection will fail. But occasionally, with probability 1 in 256, the message will decrypt successfully, and Mallory will learn a single byte of the session cookie.

The malicious JavaScript will then slightly alter its requests to put a different byte of the session cookie into the particular place, and the router will again reorganize the outgoing messages. Again, most of the time this will result in the connection being broken because it doesn't decrypt properly, but occasionally it will work, disclosing to Mallory another byte.

This process can continue until Mallory has learned the entire session cookie. She can then do with it whatever evil thing she wants.

TLS 1.0 and newer versions perform more robust validation of the decrypted data and as such are not susceptible to the same problem. But for SSLv3 there's no fix. The BEAST flaw was in a similar position. It was partially mitigated by switching to different encryption algorithms (though those encryption algorithms have abundant security problems of their own) and some changes to SSL clients to change the way they assembled messages. It may be technically possible to make similar workarounds for POODLE, but much SSLv3-using software, in particular Internet Explorer 6 on Windows XP, is no longer supported or updated. As such, it will be vulnerable forever, adding to the growing laundry list of other flaws that Windows XP is perpetually vulnerable to.

This has led some to say "enough is enough" and disable SSLv3 at the server side entirely. CloudFlare announced that it was disabling SSLv3 by default from its servers, and it's likely that others will follow suit. Killing SSLv3 is the only robust protection against SSLv3's flaws. CloudFlare says that only 0.65 percent of its HTTPS traffic used SSLv3, so disabling the protocol should not prove too onerous.

Web users can, and should, also disable SSLv3 in their browsers. Firefox 34 will disable SSLv3 by default. In the meantime, this page has instructions for Internet Explorer and Chrome, and this tells Firefox users what to do. The situation for Chrome is currently a little unsatisfactory, as it uses a command-line switch to disable SSLv3 rather than a setting. If that switch is not used (for example, if the browser is launched by clicking a link in an e-mail rather than through a shortcut) then SSLv3 will remain enabled.