We don’t seem to go far these days without the next “catastrophic” bug hitting the internets. Remember how a few weeks ago Shellshock was going to end the internet as we know it? If you believed all the headlines, that sucker was going to own us through our light globes (I suspect some poetic license was taken on my IoT comments) and the web would never be the same. Scroll forward and it’s already “Shell-what?”
Earlier this year it was Heartbleed and it too was destined to bring the internet to its knees. Except it didn’t. Whilst I’ve no doubt a number of sites got well and truly screwed over by it (Shellshock too, for that matter), it was over-inflated yet in some ways the hysteria served a positive purpose in that it got massive airtime and inevitably more attention than it would have had we all responded a little more rationally.
Which brings us to POODLE. Whilst I doubt we’ll see the same mass hysteria as we did last month, it is (and will continue) hitting the news and like the other two biggies this year, it’s serious enough to warrant attention and obscure enough to result in wild speculation and a general misunderstanding of the underlying risk. Let me share what I know based on the questions I’m hearing.
Enough with the crazy bug names, why Poodle?!
No, not Poodle, POODLE – the Padding Oracle On Downgraded Legacy Encryption. In the modern era of fancy bug names, the guys who names this must have been ecstatic when they realised that the acronym actually made a whole heap of sense! But really, that’s exactly what it is – a protocol downgrade support that then exploits a legacy encryption implementation. Nice one guys!
Who found this one?
A few blokes from Google this time, Bodo Möller, Thai Duong and Krzysztof Kotowicz. You may remember Thai from such bugs as the ASP.NET Padding Oracle from 2010. Smart guy.
Anyway, the three of them wrote a paper last month titled This POODLE Bites: Exploiting The SSL 3.0 Fallback which talked about the risk I’ll describe in this post. It’s making news today as the paper has been released, the proverbial penny dropped about the impact on our “secure” comms and now everyone from journos to sys admins are scrambling to get on top of it.
So what are we downgrading from and to?
It all comes down to SSL, its successor known as TLS and the versions spread across them. It goes like this:
- SSL 1.0: Dates back to the early 90s and was never publicly released
- SSL 2.0: From 1995 and met a need in a rapidly emerging web world, but was rather buggy
- SSL 3.0: Launched in ‘96 and solved a bunch of issues from 2.0 via a complete redesign
- TLS 1.0: Came into being in ‘99 and was an evolutionary improvement on SSL, albeit one without interoperability
- TLS 1.1: RFC from 2006 and contains various defences against attacks on earlier versions
- TLS 1.2: This time from ‘08 with a bunch of features to strengthen the cryptographic implementation
There’s a TLS 1.3 in draft spec so we’ll skip that for now, the important thing is to illustrate a continuous evolution of the construct that secures traffic in transit. Each subsequent version improves on its forefathers, often addressing bugs of varying severity that potentially undermined the very purpose of transport layer security.
What’s the deal with “downgrading”?
The problem is that the internet has a whole heap of moving parts which evolve independently of each other. Think about the current state – we’ve still got a heap of Windows XP boxes from 2001 which somehow still need play nice with the modern web. You fire up, say, Internet Explorer 6 on one of those and smart websites will downgrade the experience. You won’t get SVGs, you’ll get GIFs. You won’t get rounded corners on HTML elements, you’ll get square ones.
And so it is with SSL; when two parties (say a browser and a server) are at different stages of evolution and offer support for different versions, they could either throw their hands up and say “We just can’t get along” or they can compromise and fall back to a common version they can both support. The latter is the more usable so that’s what often happens. (Incidentally, this happens implicitly and without user interaction. It’s a “feature”.)
The problem with POODLE comes when the connection is downgraded to use SSL 3.0 when higher level TLS comms fail. If an attacker in the middle of a connection can cause this failure then they may be able to force the browser to do exactly what it’s designed to do – fall back to SSL 3.0 and try again. The real problem here is that it’s not a proper protocol version negotiation where one party says “What ya got” and the other says “I got version X” and they both agree on the protocol, rather it’s one party going “This didn’t work, let me try something weaker”. Why this didn’t work doesn’t feature in the discussion, it just causes an automatic downgrade of the protocol.
Ok, so what’s wrong with just talking via SSL 3.0?
Good question! I mean SSL 3.0 did us well for many years without the internet self-imploding, right? Well yes, but there were numerous risks of varying severity found and it’s a rather serious one that caused all the recent fuss. There’s a very good blog post on this from Adam Langley who works on Chrome and it ultimately boils down to another padding oracle attack (that’d be the “POO”).
If you recall from the aforementioned ASP.NET padding oracle blog post, it all has to with how encrypted strings are padded out to be a consistent byte length. In the case of POODLE, the attacker needs the victim’s browser to make hundreds of requests in order to actually exploit the risk. From the original security advisory by the Google guys:
Encryption in SSL 3.0 uses either the RC4 stream cipher, or a block cipher in CBC mode. RC4 is well known to have biases [RC4biases], meaning that if the same secret (such as a password or HTTP cookie) is sent over many connections and thus encrypted with many RC4 streams, more and more information about it will leak.
Right, so how are we going to get the browser to make all those requests? Well you still need to be able to mount a man in the middle attack (which of course is exactly what SSL is there to protect encrypted traffic against) after which you’re then going to want the victim to load the target site over HTTP which if you control the connection, isn’t hard. Then, well, they describe it best in that advisory:
To launch the POODLE attack, run a JavaScript agent on evil.com (or on http://example.com) to get the victim’s browser to send cookie bearing HTTPS requests to https://example.com, and intercept and modify the SSL records sent by the browser in such a way that there’s a non negligible chance that example.com will accept the modified record. If the modified record is accepted, the attacker can decrypt one byte of the cookies.
There’s not a detailed POC in the advisory (do share if one turns up later), but it’s clearly not a trivial attack, at least not compared to the “Here, just make an HTTP request to a server” attack vector that Shellshock presented. It also only appears to get cookies and auth headers at this time. “Only” probably undersells the risk though because these are very important pieces of data that could then easily lead to session hijacking if disclosed, but it’s not the entire request and response at risk here. Mind you, if you own the session then you’d be able to get a lot of the data in that anyway!
Why bother with supporting SSL 3.0 at all?
Good question, easy answer – Internet Explorer 6. Yes, the browser that everyone loves to hate (except when it first launched and was actually quite good) does not offer support beyond SSL 3.0 so no TLS. What you have to remember is that this browser was absolutely dominant. In fact depending on where you are in the world, only 4 years ago it had up to 60% of the browser market share. We shouldn’t only blame IE 6, but it hung around for an awful long time after all the other browsers had moved past SSL 3.0. (In fairness, IE 7 and later also moved past it but IE 6 had a very, very long tail.)
IE 6 has now tapered off to near obscurity, but that doesn’t change the fact that there are a whole heap of websites stood up during its heyday (and before) which still offer support for SSL 3.0. You could pretty much kill it in most places today, but you’ve also got to remember that there are a heap of other clients out there talking over HTTPS which may depend on falling back to SSL 3.0. I’m not sure, for example, if some early generation smart TVs will simply stop working if TLS is required by the server. It’s the uncertainty that keeps these early generation technologies alive.
What about on the browser end, can you just disable it there?
Yep, you sure can, for example you can define a minimum TLS version in Firefox:
It defaults to 0 which effectively means no minimum and SSL 3.0 will still play nice. Setting it to 1 will resolve the fall back risk as SSL simply won’t work anymore.
As for Chrome, there’s a patch pending that sets the minimum fall back version to TLS 1.0 but apparently it’ll be a few weeks until we see that released into Chrome’s stable channel as it has obvious potential risks relating to compatibility. There’s guidance on the Ask Ubuntu forum about disabling support for SSL 3.0 for Chrome on Linux, I’ve not looked into a way to disable it on Windows so please leave a comment if you have a process for that.
For Internet Explorer and the rest of the Microsoft stack that talks over HTTP, today they released Security Advisory 3009008 which details how to disable it via group policy.
But that’ll just break sites that need SSL 3.0 won’t it?
Ah, good point, yes! This is where TLS_FALLBACK_SCSV is getting a lot of press today, not least of all from Google themselves. The problem with many fall back implementations is that they essentially say “oh crap, that didn’t work, let’s pick an earlier TLS / SSL implementation and give that a go”. This isn’t particularly intelligent as the problem may never have been lack of support for, say, TLS 1.1 rather it was just a dodgy connection.
TLS_FALLBACK_SCSV takes a much more intelligent view of gracefully degrading the supported transport layer security implementation. You never want a protocol downgrade as it poses obvious risks so what TLS_FALL… etc does is this (from the RFC):
The TLS_FALLBACK_SCSV cipher suite value is meant for use by clients that repeat a connection attempt with a downgraded protocol in order to avoid interoperability problems with legacy servers.
That’s your fall back scenario, now the client can specify its preference on how it would like to communicate:
If a client sends a ClientHello.client_version containing a lower value than the latest (highest-valued) version supported by the client, it SHOULD include the TLS_FALLBACK_SCSV cipher suite value in ClientHello.cipher_suites. (Since the cipher suite list in the ClientHello is ordered by preference, with the client's favorite choice first, signaling cipher suite values will generally appear after all cipher suites that the client actually intends to negotiate.)
In other words, fall back but tell the server what protocol the client would prefer. This resolves attacks that attempt to downgrade the connection in that even if the communication via higher level protocols is disrupted, the client can still tell the server how it would like to communicate even though it may be telling it that over a weaker protocol.
Of course this won’t solve the risk of talking over SSL 3.0 when there’s simply no newer alternative, but it solves the “we still have SSL 3.0 around because legacy” scenario. The greatest limitation now, however, seems to be that it’s only supported in Chrome and on Google’s services. I’d love someone to prove me wrong, but from what I can ascertain, support is very, very limited right now.
What about disabling it on the server?
Here’s the thing – you can only talk over SSL 3.0 if both the client and the server support it. This means two things:
- As a consumer, you can entirely circumvent the risk by using a browser with SSL 3.0 disabled. If the server requires 3.0, things will break.
- As a website owner, you can entirely circumvent the risk by disabling SSL 3.0 on the site. If the client requires 3.0, things will break.
Only one side needs to take action for the risk to be addressed, but it also means that either side can break their things if the other party simply hasn’t gotten with the times.
The next question, of course, is how you disable it on the server side. Unsurprisingly, the guidance differs based on your server of choice. Fellow MVP André Klingsheim has a good post on Hardening Windows Server 2008/2012 and Azure SSL/TLS configuration. If you live in an Apache world then check out Disable SSLv2 and SSLv3 in Apache. Other servers are a Google search away, it’s usually a trivial configuration change. Do be conscious though – this could break things. It’ll likely be a rare occurrence, but it could be important enough to care about.
But just in case you want a good precedent to refer to, CloudFlare have disabled SSL 3.0 support altogether. Won’t somebody please think of the older browsers!! Well yes, but they also stated that this would adversely impact a mere 0.09% of their traffic.
How can I test if a site still supports SSL 3.0?
Couple of options here with the first being poodlescan.com. Yes, this is a thing already.
The other more tried and tested option is Qualys’ SSL Labs test. This is a long time favourite that tests a bunch of different SSL implementation details and includes the supported protocols in the report.
Both of these tests will show very broad-reaching support for SSL 3.0. In that regard, the scope of this risk if very large.
Is this as bad as Heartbleed and Shellshock?
No, not by a long shot. To begin with, they were (are) both remotely exploitable. You can be sitting on the beach pwning machines on the other side of the world. POODLE needs the attacker to get in the middle of the traffic so there’s your classic “attacker in the coffee shop” or the good old Wifi Pineapple (or equivalent).
In all likelihood, the greatest risk will come from those who control internet infrastructure. For example, the Iranian government played a pretty pivotal role in using DigiNotar certificates to intercept their citizen’s traffic. Attacks against the transport layer make a lot more sense when you control all the ingress and egress traffic for an audience as broad as an entire nation.
That’s not to downplay the risk – SSL / TLS / HTTPS has a critical role to play and indeed that’s why we (hopefully) invest so much effort into getting it right in our web assets. What’s different about POODLE though is the ease of the attack, the sophistication required to mount it, the scope with which it can be applied and the impact when it’s successful. None of those attributes holds a candle to Heartbleed and Shellshock.
Any other insights?
Finally, a point on the importance of keeping software current: The number of times I’ve seen people say “Oh version X works just fine for me, I don’t need to upgrade”. It’s events like this which serve as a reminder that what is “fine” today can be suddenly broken beyond repair tomorrow. If you’re running IE 6 today (yes, there are still some) and you don’t have a choice in upgrading because “reasons”, you’re stuffed. Next time it might be a vulnerability with Windows XP and it’ll be “no support for you”. We may not be able to see individual events like this coming, but the pattern of vulnerabilities appearing which can be addressed in newer versions of the software but leave the aging ones at risk is now very well established.
Edit, 21 Oct 2014: I've just published a post on Disabling SSL 3 in Azure websites (and why it doesn’t look like you have), check it out if you're working in an Azure website world.