Five days after the POODLE disclosure from Bodo Möller, Thai Duong, and Krzysztof Kotowicz at Google and the engagement work this week has been about getting SSL 3.0 disabled across the portfolio. The vulnerability — CVE-2014-3566 — is a padding-oracle attack against SSLv3 in CBC mode that allows decryption of approximately one byte of plaintext per 256 requests. With JavaScript-driven request generation from the attacker (which is feasible if the attacker can man-in-the-middle the connection), one byte at a time becomes a session cookie in approximately fifteen minutes of attack time. The attack works against SSLv3 specifically; TLS 1.0 and later have a different MAC structure that does not have the same padding-oracle exposure. The structural answer is to disable SSLv3 entirely, which is what the security community has been recommending for several years and which has finally become operationally pressing.
The protocol-downgrade angle is the part that makes POODLE operationally serious. SSLv3 is not the default for any modern browser-server pair — every reasonably current TLS deployment will negotiate TLS 1.0 or later by default. The downgrade vector exploits the fact that some browser implementations, when the initial TLS handshake fails for any reason (network glitch, transient server issue, anything), will retry with progressively-older protocols including SSLv3. An attacker who can interfere with the initial handshake — which a man-in-the-middle attacker can do — can force the downgrade to SSLv3, after which the padding-oracle attack works. The implication is that any browser-server pair where the server supports SSLv3 is potentially exposed to a POODLE-shaped attack regardless of what the client and server would normally negotiate. The structural answer at the server side is therefore to disable SSLv3 entirely, refusing to negotiate it even as a fallback. The structural answer at the client side is to refuse to fall back from TLS 1.0 to SSLv3, which Mozilla and Google have committed to in their respective browser updates this week.
The deployment work over the past week has been a tour of the engagement portfolio's TLS configurations. The good news: most clients had already disabled SSLv3 in some places — at the major load-balancers, at the front-of-house web infrastructure, at the API gateways. The less good news: several clients had SSLv3 still enabled at internal services, at legacy administrative interfaces, at vendor-supplied appliances that did not expose the configuration option to disable it. The vendor-appliance angle is the part that has produced the most operational friction; we have several engagement clients who are running appliances that ship with SSLv3 enabled and that the vendor has not yet shipped a firmware update to address. The mitigation in those cases is network-segmentation work to limit who can reach the affected appliance, plus aggressive vendor-engagement to get the firmware update prioritised.
The wider point — and this is the point that POODLE makes alongside Heartbleed and goto fail — is that the TLS protocol stack as deployed in 2014 has substantial fragility at multiple layers. The protocol itself has had bugs (BEAST in 2011, CRIME in 2012, Lucky 13 in 2013, now POODLE); the implementations have had bugs (Heartbleed, goto fail); the trust infrastructure has had compromises (Comodo and DigiNotar). Any individual issue is recoverable; the cumulative shape is that the TLS infrastructure is meaningfully less robust than the controls frameworks pretend it is. The structural response is, again, what I have been writing about since the post-Snowden long-form piece in May: assume the trust chain is contested, design for compromise of any single layer, monitor for indicators of compromise at every layer.
For the Hedgehog SOC, the POODLE-related detection content is bounded — the attack is hard to detect at the network layer because the attacker traffic looks like legitimate TLS traffic, the success of the attack is invisible without endpoint-side telemetry. What we are doing instead is monitoring for the protocol-downgrade pattern that the attack requires: any TLS connection from a client that initially negotiates a higher protocol but then renegotiates with SSLv3 is a strong signal of either an attempted POODLE attack or a browser configuration issue that should be investigated. The detection signal is clean enough to be operationally useful; the false-positive rate against the engagement client base over the past three days has been low.
The narrower question about whether to maintain SSLv3 support for the small population of users who actually need it — typically users on Windows XP with very old IE versions, or on legacy embedded devices — has been resolved in the engagement-team material as "no". The security cost of maintaining SSLv3 for the bottom 0.3% of users is now outweighed by the security benefit to the other 99.7%. Several clients are taking the operational hit of breaking access for their oldest-software users, and providing browser-upgrade assistance where appropriate. The IE 6 problem was always going to require a forced cutoff at some point; POODLE is the moment that makes the cutoff easy to justify.
The next post is probably the post-Shellshock-and-POODLE cumulative-vulnerability post that I have been drafting through October — there is something to write about how 2014 has been the year that the under-appreciated-infrastructure problem has been demonstrated at multiple points — or whatever else surfaces. The Adobe Flash continued exploitation through the autumn is also worth writing about; I expect to do that piece before the end of November.