POODLE

October’s POODLE attack affected CBC-mode cipher suites in SSLv3 due to SSLv3’s under-specification of the contents of the CBC padding bytes. Since SSLv3 didn’t say what the padding bytes should be, implementations couldn’t check them and that opened SSLv3 up to an oracle attack.

We’re done pretty well at killing off SSLv3 in response to that. Chrome 39 (released Nov 18th) removed fallback to SSLv3 and Chrome 40 is scheduled to remove SSLv3 completely. Firefox 34 (released Dec 1st) has already removed SSLv3 support.

We’re removing SSLv3 in favor of TLS because TLS fully specifies the contents of the padding bytes and thus stops the attack. However, TLS’s padding is a subset of SSLv3’s padding so, technically, you could use an SSLv3 decoding function with TLS and it would still work fine. It wouldn’t check the padding bytes but that wouldn’t cause any problems in normal operation. However, if an SSLv3 decoding function was used with TLS, then the POODLE attack would work, even against TLS connections.

This was noted by, at least, Brian Smith on the TLS list ([1][2]) and I was sufficiently cynical to assume that there were probably more instances of this than the old versions of NSS that Brian cited, and so wrote a scanner for the issue.

Unfortunately, I found a number of major sites that had this problem. At least one of whom I had good enough contacts at to quickly find that they used an F5 device to terminate connections. I contacted F5 on October 21st and they started working on a fix. Yngve Pettersen also independently found this issue and contacted me about it around this time.

Read more, the original post from ImperialViolet

Check with the excellent functionality from Qualys SSL Labs if you have a weak SSL setup.

The attack, POODLE, is similar to the BEAST attack and also allows a network attacker to extract the plaintext of targeted parts of an SSL connection, usually cookie data. Unlike the BEAST attack, it doesn’t require such extensive control of the format of the plaintext and thus is more practical.

Fundamentally, the design flaw in SSL/TLS that allows this is the same as with Lucky13 and Vaudenay’s two attacks: SSL got encryption and authentication the wrong way around – it authenticates before encrypting.

A complete description of the flaw can be found at: ImperialViolet

Here some counter measurements that can also be found in the original article.

Chrome users that just want to get rid of SSLv3 can use the command line flag –ssl-version-min=tls1 to do so. (We used to have an entry in the preferences for that but people thought that “SSL 3.0” was a higher version than “TLS 1.0” and would mistakenly disable the latter.)

In Firefox you can go into about:config and set security.tls.version.min to 1. I expect that other browser vendors will publish similar instructions over the coming days.
As a server operator, it is possible to stop this attack by disabling SSLv3, or by disabling CBC-mode ciphers in SSLv3.