Just a quick one as it’s mostly explained in How to Disable SSL 3.0 in Azure Websites, Roles, and Virtual Machines, but there are a few bits worth adding. Oh – just in case POODLE was news to you, go back and read my post on Everything you need to know about the POODLE SSL bug from last week.
Back to Nazim’s guidance above on Azure websites, you can either install a site extension to disable SSL 3 or make a URL rewrite rule that looks at a custom header in the request. My view is that the latter is always preferable as it puts it right into the config of the site. Deploy it somewhere else later and the config is still good (assuming it’s an Azure website that recognises the setting). I can see some people preferring the site extension as it means you don’t need to redeploy the site, but if you’re worried about that then you probably have some bigger problems to deal with!
Now, before deploying the fix, let’s make sure that SSL 3 is indeed enabled because personally, I like to see evidence that changes I’m making actually do something. Here’s a Qualys SSL Labs scan of the site before any changes:
Here we can see SSL 3 still alive and kicking and indeed a very handy warning about the POODLE risk. Now let’s take the fix which is a URL rewrite rule which looks just like this:
<!-- Defending against POODLE --> <rule name="Block SSL3.0" patternSyntax="Wildcard" stopProcessing="true"> <match url="*" /> <conditions> <add input="{HTTP_X_FORWARDED_SSL30}" pattern="1" /> </conditions> <action type="CustomResponse" statusCode="403" subStatusCode="900" statusReason="Forbidden" statusDescription="SSLv3 connections are forbidden by this site" /> </rule>
This is just Nazim’s config and it’s a very straight forward rewrite rule. It looks at the request coming to the site and if it has a header named “{HTTP_X_FORWARDED_SSL30}” it simply returns an HTTP 403. Why? Good question…
It all has to do with Azure websites being a PaaS offering where whilst you have control over the site, you don’t have control over the underlying OS configuration and that’s the place you’d normally disable SSL 3. Adding to that, SSL is terminated upstream of the server the site is actually running on and it’s done so on shared infrastructure (this is also where the header above is added to the request before it hits the website). The bottom line is that you, as an individual, have no control over the SSL configuration. By adding that new header when SSL terminates, the website can be aware of which version of the protocol was used and act accordingly. It’s a pretty neat little trick actually.
So why not just turn it off altogether? I mean disable it at the SSL endpoint in front of the Azure websites? Not much will break anyway as nobody is using it any more, right? Almost nobody and therein lies the problem. As it turns out, people get a bit cranky if you break their things, even if it’s only a tiny percentage of people and a tiny percentage of things. Clearly the Azure guys have looked at the situation and weighed up the impact of turning it off altogether versus what might happen if it’s exploited and felt that the best middle ground was to make it configurable. Yes, this means that taking no action leaves you vulnerable and it’s not as aggressive as, say CloudFlare’s approach, but certainly this would have been a measured decision. SSL 3 will die a natural death at some point and inevitably be disabled full stop, but clearly Microsoft thinks it’s just a bit too early to do that across the board on Azure.
Moving on, I’ve pushed the config change, let’s check that SSL Labs scan now:
Uh, ok, what gives? We’re still POODLE’able!
Here’s the thing – when you “disable” SSL 3 using this approach, you’re not really disabling it. Remember how I said SSL terminates upstream of the website and you’ve really only got any control over the site itself? From the scan point of view, the SSL connection using v 3 is working as it’s successfully terminating at the appliance in front of the Azure website. That the website will then respond with a 403 does not appear to affect this test.
So what’s to be done? Well firstly, let’s make sure the change is actually working and that’s a simple task. Here’s the website with the URL redirect loaded in Internet Explorer:
Business as usual there, that’s just fine. Now let’s tweak some settings:
See where this is going? We’re forcing IE to talk over SSL 3 only (it’s the easiest to configure in Microsoft’s browser), let’s see how that works out now:
And there’s a 403 – the website has not processed the request as it normally would when it supported SSL 3, rather the URL rewrite rule has kicked in and responded first.
So does this actually solve the problem? Kind of. POODLE is exploited by looking at how the web server responds to requests sent via SSL 3 so in that regard, this problem is nipped (ok, just one canine analogy) in the bud. On the other hand, an SSL connection can still be “made” in that the negotiation with the SSL end point can still occur over v 3. It doesn’t matter whether it’s the Qualys SSL Labs test or even just a direct connection using OpenSSL, you’ll likely find that many of these tests will report SSL 3 as being enabled as they’re simply looking for the handshake over v 3 to confirm or deny its presence.
Where the challenge may well lie for many people is that they will be told their Azure website still supports SSL 3 and therefore fails whatever corporate policy has been devised to deal with POODLE. Some explanation may well be required here: “Yes, a successful handshake can still occur over SSL 3, but no, the site is no longer at risk of a POODLE attack as it won’t return a valid response”. Until the earlier mentioned balance Microsoft have struck around not killing those few remaining SSL 3 dependencies, some objectivity will be required by those assessing the risk on Azure websites.
Update, 23 Oct 2014: There's been some great discussion in the comments and it's quite rightly raised issues that I haven't addressed well so let me clarify here now:
By responding with a 403 when a resource is requested via SSL 3, the website will no longer present a login page and no longer offer the opportunity for a cookie to be set and consequently stolen. Of course it doesn't have to respond with a 403, now that there's a request header that can be read you can implement whatever behaviour you like but as a default position, that certainly breaks the site to the extent that you can no longer login. However, it doesn't protect requests that already have the cookie. By extension, it also doesn't protect users who don't have their connection downgraded during the login but do after the login, whether that be by coincidence or clever hacker design.
The other thing worth noting is that the SSL Labs response does indicate something important: the RC4 cipher has been prioritised above CBC which is the vulnerable cipher in a POODLE attack. This is alluded to in the "POODLE mitigated" message above then explained further down the page. If someone gets MitM'd and their connection successfully downgraded to SSL 3 after they login and already have a cookie of value, they'll talk via RC4 which whilst acknowledged as having it's own issues, is not the cipher suite described in the advisory.
Ultimately, SSL 3 need to get disabled and as I've said above, this will inevitably happen at some point. Whilst the mitigations above aren't perfect, they do significantly raise the bar for an attack to be successful.
Further to this, see Nazim's comments about disabling SSL 3 for Azure websites. He doesn't give a timeframe, but he does state that it's high priority.