May 29, 2017

POODLE and the fundamental market failure of browser security

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:

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. 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.


  1. And what of embedded/cli browsers, lynx, curl, wget, etc.?

  2. 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.

  3. 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.

  4. Nice post! Worth noting that immediately redirects to, which has SSLv3 correctly disabled. I suspect a lot the top Alexa domains listed on are similar.

  5. 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.

  6. Alex Gaynor says:

    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.

    • John Millington says:

      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.

  7. 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.

  8. Darian Smith says:

    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…

  9. 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.

  10. ]))'”)’)()

  11. 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.