The POODLE Attack and the End of SSL 3.0


SSL version 3.0 is no longer secure. Browsers and websites need to turn off SSLv3 and use more modern security protocols as soon as possible, in order to avoid compromising users’ private information.

We have a plan to turn off SSLv3 in Firefox. This plan was developed with other browser vendors after a team at Google discovered a critical flaw in SSLv3, which can allow an attacker to extract secret information from inside of an encrypted transaction. SSLv3 is an old version of the security system that underlies secure Web transactions and is known as the “Secure Sockets Layer” (SSL) or “Transport Layer Security” (TLS).


In late September, a team at Google discovered a serious vulnerability in SSL 3.0 that can be exploited to steal certain confidential information, such as cookies. This vulnerability, known as “POODLE”, is similar to the BEAST attack. By exploiting this vulnerability, an attacker can gain access to things like passwords and cookies, enabling him to access a user’s private account data on a website.

Any website that supports SSLv3 is vulnerable to POODLE, even if it also supports more recent versions of TLS. In particular, these servers are subject to a downgrade attack, in which the attacker tricks the browser into connecting with SSLv3. This relies on a behavior of browsers called insecure fallback, where browsers attempt to negotiate lower versions of TLS or SSL when connections fail.

Today, Firefox uses SSLv3 for only about 0.3% of HTTPS connections. That’s a small percentage, but due to the size of the Web, it still amounts to millions of transactions per day.


The POODLE attack can be used against any browser or website that supports SSLv3. This affects all current browsers and most websites. As noted above, only 0.3% of transactions actually use SSLv3. Though almost all websites allow connections with SSLv3 to support old browsers, it is rarely used, since there are very few browsers that don’t support newer versions of TLS.

Sites that require SSLv3 will remain vulnerable until they upgrade to a more recent version of TLS. According to measurements conducted by Mozilla and the University of Michigan, approximately 0.42% of the Alexa top million domains have some reliance on SSLv3 (usually due to a subdomain requiring SSLv3).


SSLv3 will be disabled by default in Firefox 34, which will be released on Nov 25. The code to disable it is landing today in Nightly, and will be promoted to Aurora and Beta in the next few weeks. This timing is intended to allow website operators some time to upgrade any servers that still rely on SSLv3.

As an additional precaution, Firefox 35 will support a generic TLS downgrade protection mechanism known as SCSV. If this is supported by the server, it prevents attacks that rely on insecure fallback.

Additional Precautions

For Firefox users, the simplest way to stay safe is to ensure that Firefox is configured to automatically update. Look under Preferences / Advanced / Update and make sure that “Automatically install updates” is checked.

For users who don’t want to wait till November 25th (when SSLv3 is disabled by default in Firefox 34), we have created the SSL Version Control Firefox extension to disable SSLv3 immediately.

Website operators should evaluate their traffic now and disable SSLv3 as soon as compatibility with legacy clients is no longer required. (The only remaining browser that does not support TLSv1.0 is Internet Explorer 6). We recommend following the intermediate configuration level from Mozilla’s Server Site TLS guidelines.

We realize that many sites still receive traffic from IE6 and cannot disable SSLv3 entirely. Those sites may have to maintain SSLv3 compatibility, and should actively encourage their users to migrate to a more secure browser as soon as possible.

74 responses

  1. Yuhong Bao wrote on :

    “We realize that many sites still receive traffic from IE6 and cannot disable SSLv3 entirely. Those sites may have to maintain SSLv3 compatibility, and should actively encourage their users to migrate to a more secure browser as soon as possible.”
    Or if you absolutely have to use IE6, go to Internet Options’s Advanced tab and check TLS 1.0 and while you are at it uncheck SSL 2.0. But of course the preferred solution is to upgrade and while you are it please also remind users to update to XP SP3 if you hasn’t already. There is no WGA check in WinXP service pack in general, despite such misconceptions.

    1. Daniel Veditz wrote on :

      _We_ don’t have to use IE 6, and if the IE 6 users who are looking for Firefox can’t get to our site where do we teach them how to turn on the TLS 1.0 option?

      1. Yuhong Bao wrote on :

        I am not talking about browser download sites, for which I agree that it is not worth the effort.

      2. Vaidik Kapoor wrote on :

        As I understand it, TLS versions before 1.1 are not secure either. Read:

        1. Robin Craig wrote on :

          According to “TLS 1.0, TLS 1.1, TLS 1.2, and all cipher suites that do not use CBC mode are not affected.”

        2. Robin Craig wrote on :

          According to
          “TLS 1.0, TLS 1.1, TLS 1.2, and all cipher suites that do not use CBC mode are not affected.”

  2. Mara Alexander wrote on :

    Then could you explain why I am unable to connect to *any* site that uses SSL when I disabled all security.ssl3.* prefs in about:config (per this support post:

    After reenabling/toggling them to the default of true I can still not access my own server where I just disabled SSLv3 (trying from two different compauters using Firefox 32.0.3). Chrome has no problem accessing my server. Cache isn’t an issue, I also cleared my history including active logins.

    I realize this isn’t a proper support channel, but at the same time, I have to ask if you did any sort of testing before writing this? You’re advocating servers disable SSLv3, which is great, but if Firefox for whatever reason *requires* SSLv3… the advice is pretty stupid.

    1. Daniel Veditz wrote on :

      Those preferences are badly named, or perhaps it would be more accurate to say they are “historically” named. Since only programmers were expected to see those internal names no one bothered to change all the names from security.ssl3. to security.tls.. Those preferences control which ciphersuites are enabled for both SSLv3 and TLS, and if you turn them all off then you will not be able to connect to any TLS servers.

      You’ll want to leave those preferences alone and instead install the restartless add-on mentioned in the article. If you insist on manual preference twiddling then you want to change the preference security.tls.version.min from 0 (sslv3) to 1 (tls 1.0).

      1. Bob wrote on :

        I’m currently stuck with ESR 24. How can I test that changing security.tls.version.min to 1 is having the desired effect? If I set it to 9999999, https sites still load, which it seems like they should because 9999999 is a silly value.

        1. Daniel Veditz wrote on :

          It’s quite likely the code sees the silly value and ignores it, using the default (0) instead. The way to test it is to visit some site known to be sslv3-only, or a site explicitly designed to test this issue such as and

      2. nathan wrote on :

        Thank you, Daniel for the thoughtful reply to a disrespectful request.

        1. Orzowei wrote on :

          Yeah, calling the developers that are trying to solve your problems “stupid” it’s not the nicest of things to say.

          Well done, Daniel. Shame on you, Mara.

      3. Mara Alexander wrote on :

        The addon works fine, thank you.

        There is still a problem with being able to connect to any port besides 443 with SSL. cPanel uses 2083, 2087, 2093, exim uses 465, 587. None of those are accessible from Firefox when SSL3 is turned off server-side, though Chrome has no problem connecting.

        Apparently the rumor that Firefox does not support TLS on any port that is not 443 is true, and considering there are millions of cPanel users, this needs to be addressed, sooner than later.

        1. Richard Barnes wrote on :

          I am unable to reproduce this issue. With the following server, Firefox connects just fine to https://localhost:2083/

          openssl s_server -accept 2083 -cert cert.pem -key privkey.pem -no_ssl3

          1. Mara Alexander wrote on :

            It’s not just me.

  3. Mara Alexander wrote on :

    I changed the server cipher list from: ALL:!ADH:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP

    and Firefox won’t connect (while Chrome has no problem doing so). The specific error message:

    Secure Connection Failed

    An error occurred during a connection to Cannot communicate securely with peer: no common

    encryption algorithm(s). (Error code: ssl_error_no_cypher_overlap)

    The page you are trying to view cannot be shown because the authenticity of the received data could not be verified. Please contact the website owners to inform them of this problem.

    So again, it appears that Firefox is requiring SSLv3 in order to connect.

    1. Vyronas Tsingaras wrote on :

      What version of OpenSSL/GnuTLS and Apache/nginx on the server? Can you post logs?

      1. Mara Alexander wrote on :

        Apache 2.2.29, OpenSSL 1.0.1e-fips. The problem appears to be that Firefox doesn’t support TLS on any port besides 443. cPanel uses 2083, 2087, 2093, exim uses 465, 587, etc.

        Nothing remarkable in the logs, only the error message (stated above) in the browser. Meanwhile I could connect just fine through Chrome, so this points to a (Firefox) browser problem, not a server misconfiguration.

        1. ITGabs wrote on :

          Yes, I was reading this and the Cpanel post too, I have exactly the same issue, after I disabled SSL 3.0 in Apache , Firefox not let me connect to cpanel, where in Chrome is no problem at all.

          Same config as Mara Alexander

    2. Daniel Veditz wrote on :

      SSLv2 has been exploitable since the mid 1990’s, please don’t enable that on your server.

      Our recommended server configurations, which we know work with Firefox, are listed at Firefox does not require SSLv3 to connect.

      1. Mara Alexander wrote on :

        What would make you think I had or was planning to enable SSL2? The cipher clearly shows “-SSL2.”

        Apparently it’s not the protocol but the port that Firefox is having a problem with. cPanel uses 2083, 2087, 2093, exim uses 465, 587. It appears that Firefox has a problem with TLS on any port besides 443.

    3. John wrote on :

      You may find this reference useful:

    4. Simon Deziel wrote on :

      @Mara, using “-SSLv3” in your cipher list, removes so many ciphers that there is no overlap with what your browser and server both support. In fact, you end up only supporting ciphers defined in TLS 1.2.

      You should disable the SSLv3 protocol instead of trying to remove the ciphers it support.

  4. Petrol Frier wrote on :

    An important enabling issue putting most of us at risk who otherwise would not be stems from *BROWSERS* intentionally bypassing version downgrade attack protections built into the SSL protocol.

    What happens in the future if there is a problem found with TLS x.y will downgrade protections also be null and void? If so please consider at least providing an option to disable the behavior so we can better protect ourselves.

    1. Ángel wrote on :

      Petrol, SCSV will also protect from downgrades to TLS 1.x from TLS 1.y (x < y)

      1. Petrol Frier wrote on :

        SCSV not an RFC and not deployed to the worlds browser and server stacks. How many years will that take if it ever happens?

        Meanwhile I’ve deployed TLS v1.2 and it is essentially useless because browsers are bypassing the very feature intended to protect users from these types of attacks.

        1. Maik wrote on :

          SCSV has been in Chrome for a while and will be in Firefox 35. So will just take a few more months and the majority of users will have it.

          1. Petrol Frier wrote on :

            How does it help without server support?

    2. Daniel Veditz wrote on :

      Browsers were just doing what they had to to keep users happy, and servers were so badly configured that browsers had to be generous trying to connect. We’re still paying for the sins of the late 90s browser wars.

      1. Petrol Frier wrote on :

        My view you would be hard pressed to find anyone who cares about ancient history as confidence in secure commerce continues to be shaken by strings of high profile security failures. Currently as a solution downgrade SCSV is both immature and non-deployable server-side to the extent it can be expected to do much good anytime soon.

  5. Andrei wrote on :

    “SSLv3 will be disabled by default in Firefox 34”

    What about ESR? Will new version be released to replace current 24 or ESR 24 be patched?

    1. Philip wrote on :

      A release for Firefox 24 (ESR) would be highly relevant for me. It would be great, if Mozilla could publish it also for the long term versions.

    2. Richard Barnes wrote on :

      We’ll take a look at porting the patch to ESR releases. In the mean time, the SSL Version Control extension should work for those releases.

      1. gwt wrote on :

        FF 24 ESR ends today, so I hope it’s ported to FF 31 ESR.

        In fact, I don’t see any reason why it wouldn’t.

  6. James Labonte wrote on :

    Mozila provide the great update about SSL Certificate, but my concern is your blog it self using SSL 3.0 version.. Why it is not updated yet?

    1. Peter wrote on :

      They support TLS 1.0 and 1.1 as well.

  7. Kharsirr wrote on :

    Why add-on recommended in this blog post informs me about ‘Author not verified?’

  8. null wrote on :

    Can’t bypass mozilla_pkix_error_inadequate_key_size => can’t use FF >= 33 at work 🙁

    old apps/certs on internal network – hard coded blocking of anything that is NOW insecure is not the way

  9. Kharsirr wrote on :

    Addon recommended in this blog post informs me about ‘Author not verified’; why?

    1. Jorge Villalobos wrote on :

      Most add-ons display that warning on installation because they aren’t signed.

      1. Nathan Brazil wrote on :

        Which begs the obvious question, why isn’t the “officially recommended” add-on to fix a security problem signed? Before you give the obvious answers just let me say, it probably should be.

        Thank you to the entire team for the hard work that dealing with this sudden issue must have caused. Thank you to those who respond to this blog providing the help we all rely on.


    2. Randy wrote on :

      Why isn’t there a way to PLUG IN or have it load a new SSL package of some type so that when this happens it’s super easy to upgrade the browser instead of a full upgrade?
      Sometimes the changes to a new browser makes me sick, like when you make it look like a mac GUI I hate that.
      Sometimes you have to upgrade the OS just to upgrade the browser and that is a joke.
      So please make the encryption “package” part something you can easily change out.

  10. Richard wrote on :

    We run 500+ installations on ESR 24. So please give me a plugin or a howto to disable SSL 3.0. ASAP please.

    1. Richard Barnes wrote on :

      The SSL Version Control extension works with ESR 24 as of version 0.2.

  11. Brian wrote on :

    These POODLE attacks sound real bad. Let’s just hope they don’t progress into POMERANIAN attacks.

  12. gialloporpora wrote on :

    I have Aurora (Firefox 34) but I obtain the same result with ESR and Firefox 33.
    Making this test:
    it states that I am not vulnerable even if I have not disabled SSLv3.
    security.tls.version.min is set to 0.

    Is the test that fails or I am secure even if I don’t set the above preference to 1?

    1. Daniel Veditz wrote on :

      The test has been corrected. Firefox was not connecting to the test server for unrelated reasons.

  13. Adric wrote on :

    I’d like to see the extension updated to support Firefox mobile, as I do quite a bit of browsing (including the occasional purchase and banking activity) on my phone and tablet. The extension page is reporting “Not updated for firefox 33.0” when accessed via the Android version.

    1. Adric wrote on :

      Interestingly, Firefox (and Firefox Beta) on my phone both show as “Not vulnerable” at . Perhaps the extension isn’t needed on mobile after all…

      1. Daniel Veditz wrote on :

        Firefox for Android is equally affected, but you can fix it without waiting for the add-on to be updated.

        1) In the URL bar enter about:config
        2) find the pref “security.tls.version.min” — you probably want to use the search box
        3) change the value from 0 to 1

        1. Adric wrote on :

          It looks like the extension has been updated, as it’s compatible with Firefox mobile (33.0 and Beta, anyway) today. So both options are now available. 🙂

        2. John Doe wrote on :

          THIS. Mozilla should have recommended that step to disable SSL 3.0.

  14. Dan Sutton wrote on :

    Open source software. ROFL.

    1. Bob wrote on :

      That’s a strange thing to say, as this all has nothing whatsoever to do with open source. It’s a flaw in an ancient protocol which affects open and closed source software equally.

      1. Petrol Frier wrote on :

        The problem with this sentiment SSL provides secure downgrade attack protection which firefox has intentionally disabled. Without this reality SSL v3’s continued existence would be a non-issue.

    2. Sam wrote on :

      Dan, the flaw is in the design of the SSLv3 protocol, which was created by the Netscape Corporation in 1996.

    3. aint even funny anymore wrote on :

      The amount of dumb is staggering.

    4. Baab wrote on :

      The only remaining browser that fails to support better protocols is IE6. ROFL.

  15. George wrote on :

    For web sites who have patched and updated to OpenSSL 1.0.1j with TLS_FALLBACK_SCSV, how can we test this is working while having SSLv3 enabled ?

    Current POODLE SSLv3 scanners online only test if SSLv3 is enabled or disabled and not if they have TLS_FALLBACK_SCSV it seems ?


  16. DS Ullman wrote on :

    Will this be hitting the ESR in November?

  17. Evandro Roberto Laux wrote on :

    Has Internet Explorer Mobile 6 TLS support?

  18. Alex wrote on :

    Is Thunderbird vulnerable ? honest question, after all it *does* have javascript enabled by default and that seems to be one of the main requirement of POODLE.


    1. Daniel Veditz wrote on :

      Thunderbird does not have javascript enabled /in mail/, and reading mail is its main purpose for most users. You’re probably OK if that’s all you do. If you’re one of the folks who install things like the Thunderbrowse add-on then you’d be as vulnerable as any other browser user.

  19. Alex wrote on :

    I wanted to thank the Mozilla Foundation for moving so quickly to address this vulnerability. Your browser is great as far as being aware about security issues which I value greatly. It also allows for a great deal of additions to customize and make the browser your own. It is currently my favorite browser.

  20. Jason wrote on :

    I love your browser but I just want a fix so that I may access sites such as my Hotmail and Twitter again. I not a technical geek so I don’t understand much of the chatter above. I have to use IE or Chrome to access these sites and I don’t care to do that but I have no options. What to do?

    1. Daniel Veditz wrote on :

      We have not yet made any changes in Firefox relating to POODLE. If you can’t connect to Twitter and Hotmail you’re having some other problem, but there are too many possibilities to diagnose in blog comments on an unrelated issue. The giant hammer approach would be to try a “Firefox Reset” as described here:

      For anything more subtle I recommend working with the folks at (see the “Ask a Question” link at the top.

      1. Jason wrote on :

        For some reason, I don’t have a reset button on the Troubleshooting Information page. I have uninstalled and reinstalled Waterfox and the same issues persist.

More comments:1 2