POODLE detailed; how to disable SSL 3.0 in Chrome, Firefox; disabling it on servers may break IE6
POODLE attacks on SSLv3 — My colleague, Bodo Möller, in collaboration with Thai Duong and Krzysztof Kotowicz (also Googlers), just posted details about a padding oracle attack against CBC-mode ciphers in SSLv3.
Context & Ripple Effects
This write-up lands hours after Google disclosed POODLE and pushed TLS_FALLBACK_SCSV as the downgrade defense, and it is the technical companion piece: Bodo Möller, Thai Duong and Krzysztof Kotowicz lay out the padding oracle against CBC-mode ciphers in SSLv3. The pickup is unusually broad for a protocol bug — the Google Online Security Blog post was joined same-day by Mozilla Security Blog, The Register, Netcraft, Financial Times, Graham Cluley and BBC.
The practical stakes sit in two places. Client-side, guidance is out for killing SSL 3.0 in Chrome and Firefox, with Mozilla pinning removal to Firefox 34 on November 25. Server-side, the confirmed caveat is that disabling SSL 3.0 may strand Internet Explorer 6 clients — a compatibility tax that predates this bug, given Google has spent years trying to make SSL less painful, from its 2011 work through the July 2014 switch to BoringSSL.
First-order effects
- Browser vendors move immediately: Mozilla commits to disabling SSL 3.0 in Firefox 34 (due November 25), and administrators get step-by-step instructions for Chrome and Firefox today.
- Server operators who follow the disable guidance accept a real trade-off — IE6 clients lose connectivity, so sites serving legacy intranet or regional traffic must choose between exposure and breakage.
Second-order effects
- Adoption of TLS_FALLBACK_SCSV becomes the pressure point for the wider web: without it, attackers can force connections down to vulnerable SSL 3.0 even where both sides support TLS, so CDN, load-balancer and library maintainers face urgent patch requests.
- CBC-cipher suites come under audit across implementations beyond SSLv3, pushing vendors toward AEAD-based TLS configurations and accelerating work like Chrome's BoringSSL consolidation.
Third-order effects
- If browsers keep setting deprecation deadlines while servers lag, the industry settles into a pattern where legacy protocol retirement is driven by client vendors rather than standards bodies — with holdout populations like IE6 becoming the visible cost of that model.
The trend: Browser vendors are forcing the retirement of legacy crypto protocols on vendor-set timelines, leaving server operators to absorb the compatibility fallout.