Dec 8 2014
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 () 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.