Last week saw the public disclosure of the POODLE vulnerability, a practical attack allowing a network attacker to steal plaintext from HTTPS connections. In particular, this attack can be used to steal authentication cookies. It’s a bad vulnerability, and it particularly hurts because it should have been fixed long ago. It only affects the ancient SSL v3 protocol, which was marked deprecated 15 years ago with the introduction of TLS v1.0.
Support for SSL should have been disabled long ago, but as has been pointed out, browser vendors delayed because they didn’t want users to lose access to outdated servers. Unfortunately, even now that we know of the POODLE bug making SSLv3 highly insecure against a competent network attacker, Firefox is the only major browser which has announced definitive plans to kill SSLv3 for good.
Compare the responses of four major browser vendors:
- Mozilla is completely disabling SSLv3 by the end of November in Firefox.
- Google, whose engineers discovered the bug, said “In the coming months, we hope to remove support for SSL 3.0 completely from our client products.” Yet there is no definitive date because of “significant compatibility problems.” Google is rolling out some targeted patches instead-including support for the TLS_FALLBACK_SCSV extension to prevent downgrade to SSLv3, which is already deployed to Google servers.
- Microsoft downplayed the bug by saying it is “not considered high risk to customers.” They have not announced any definitive plans, but may issue patches in the future.
- Apple quietly released a patch which disables the vulnerable CBC cipher suites in Safari without disabling SSLv3 completely.
Without saying that Mozilla’s approach is correct, we can point out a simple and sad fact: by being the most aggressive about protecting their user’s security, Mozilla will probably lose market share, at least in the short run.
Consider a Firefox user next month trying to browse to an outdated server which only supports SSL. Citibank.com is the most prominent example. Firefox users will see a failure message next month trying to go to Citibank. A non-zero portion of them will switch to another browser and many of those simply won’t return. By contrast, only a tiny number of users are likely to switch to Firefox because it’s the most proactive on this issue. Only a handful of users know and care about this problem and they can manually turn SSLv3 off in the browser of their choice.
This demonstrates the fundamental market failure in browser security. Often browser vendors would like to increase security at the expense of a tiny number of outmoded web sites, but they know this will likely cost them users. It’s not hard to read between the lines of Google’s post and hear “We really want to kill SSLv3 for good, but our hands are tied because of some really irresponsible web sites out there.” I don’t mean to fault Google at all. They have world-class security engineers working on Chrome who have improved the state of HTTPS dramatically. I just wish they didn’t have to spend so much time dealing with a small number of crufty old servers. Microsoft more directly warned users that “if you turn of SSLv3, you’ll lose access to some sites so don’t come crying to us.”
There’s a similar failure on the server side, as servers which disable SSLv3 will cut off users with ancient browsers (in particular, the zombie Internet Explorer 6). That isn’t so bad in this particular case: CloudFlare, one of the larger content delivery networks, has disabled SSLv3 for all clients and reported that less than 1% of its traffic would be affected and much of that was crawlers and various attacks anyways. For other security upgrades though, support for old browsers can be just as big of a headache.
In the server case, it may be hopeless to expect thousands of entities to co-ordinate updates. But in the browser case, there really only a handful of major vendors and it’s past time to see better cooperation. They should have agreed on a date 5-10 years ago that they would all turn off SSLv3 at once, just like they should have been able to agree to kick out more Certificate Authorities which were hacked. I strongly suspect Google would ship code today to kill SSLv3 if they had a firm commitment from their competitors to do so as well. It’s a shame to see browsers feeling compelled to hold back on security for fear of losing customers to a less-secure competitor.
These cameras make it easy for your h2o adventurer to you need
to pictures on whitewater rapids also remember the exhilaration with the instant.
You will have the necessary instructions to tune into you got it
wireless receiver, make certain you get an excellent signal to receive the best movies.
Waterproof camera july 2012 At around $300, yourrrre still
getting an outstanding camera, especially with this variety of reviews we’ve put together for you.
Real estate agents use to this particular to better show their sales along with wildlife enthusiast also discover
the height extension with this innovative camera very helpful.
There are a couple of accessories that may go along
with this camera.
]))'”)’)()
I’m gone to inform my little brother, that he should also pay a quick visit this
web site on regular basis to take updated from newest
news update.
This blog focus entirely on the issue of SSL v3 while completely ignoring underlying enabling failure caused by browser vendors willfully performing insecure version rollback rather than leverage standards based secure negotiation facilities included with SSL/TLS protocol.
If browser vendors did not intentionally bypass secure negotiation continued availability of SSL v3 would not have put anyone at unnecessary risk as browsers would be incapable of being tricked into using SSL v3 while a better protocol was available.
Why is everyone silent about this? I realize piling on a long since dead protocol SSL v3 is both an easy and legitimate target yet failure to seriously address agility of security parameters in a serious way (which SCSV based solution is not) guarantees when vulnerabilities are found in newer versions of TLS we get to repeat the same epic fails all over again…and again…and again…
I was pretty pleased to uncover this page. I want to to thank you for your time
due to this fantastic read!! I definitely savored every little bit of
it and I have you saved to fav to see new stuff on your web site.
Karl: Users are not equipped to properly evaluate the security implications of these interstials. Users are barely equipped to understand the idea of plaintext vs. TLS, while many users understand that if you don’t have the green lock you shouldn’t type your credit card, almost none of them understand that without the lock, the page’s content may be modified arbitrarily.
Pushing more and more complexity onto users (and then inevitably trying to blame them when they make a mistake… how could they not!). Browsers and website operators should put the absolute maximum pressure on the other to obviate broken standards.
Frankly, TLS 1.2 came out 6 years ago, the idea that we still need TLS 1.0, much less SSLv3 is ridiculous. Just. Turn. Them. Off. The idea that you don’t update your server, and so browsers should leave broken things in to support *your* incompetence is unconscionable to me.
By that argument, browsers should drop plaintext HTTP. If they don’t drop that, they shouldn’t drop things that are _more_ secure, such as SSL3.
And while there’s such thing as Too Much complexity, the reality is that there really are _degrees_ of security, however much the browser makers want to have the browser say misleading things like “this is secure.” Once the browsers start to do a competent job of expressing this (instead of trying to pigeon-hole every connection into one of only two or three categories), then MitM-vulnerable connections can fit right into that.
There was already a minor step in the right direction anyway, when browsers started showing EV-cert-SSL connections as looking a little different than not-EV-cert ones. It just needs to get finished, is all.
Once this gets done right, then people can make insecure connections to their incompetent banks and SEE THE PROBLEM, rather than having to use a different browser to make an insecure connection to their incompetent bank and have the problem concealed from them.
Why don’t browsers take the same approach to SSLv3.0 connections that they do with invalid certificates? Just say the site isn’t safe, warn the user not to go there, and make them click a “proceed anyway” button.
And users could start posting on their Facebook timeline or Twitter, that sites like Citibank are vulnerable to POODLE, and maybe customers should look elsewhere for their banking needs.
Nice post! Worth noting that citibank.com immediately redirects to https://online.citibank.com, which has SSLv3 correctly disabled. I suspect a lot the top Alexa domains listed on poodle.io are similar.
Surely if Google were that concerned they’d just stop indexing sites which use SSL. With suitable public warnings and information on Google, it wouldn’t take long for those sites to work out why they’d disappeared from Google search results.
For as long as I can remember, the rule of thumb for communications software has been “Be strict in what you generate; be liberal in what you accept.” At this point that’s so very very wrong.
And what of embedded/cli browsers, lynx, curl, wget, etc.?