Firefox Blocking Fraudulent Certificates

Issue

Mozilla has been informed about the issuance of several fraudulent SSL certificates for public websites. The certificates have been revoked by their issuer which should protect most users. This is not a Firefox-specific issue. As part of our ongoing commitment to providing a secure Web experience for users, we have updated Firefox 4.0, 3.6, and 3.5 to recognize these certificates and block them automatically.

Impact to users

Users on a compromised network could be directed to sites using the fraudulent certificates and mistake them for the legitimate sites. This could deceive them into revealing personal information such as usernames and passwords. It may also deceive users into downloading malware if they believe it’s coming from a trusted site.

Status

Current versions of Firefox are protected from this attack. We are still evaluating the possibility of further response to this issue. We encourage all users to keep their software up to date by regularly applying security updates.

Credit

This issue was reported to us by the Comodo Group, Inc., the certificate authority responsible for issuing the fraudulent certificates.

The Conversation {24 comments}

  1. dilip {Tuesday March 22, 2011 @ 9:19 pm}

    unfortunate this happens around the Firefox 4 release

  2. Bob {Tuesday March 22, 2011 @ 9:46 pm}

    I notice that normally, once an issue is made public and gets press, you publish a post on this security blog. Why wasn’t this issue reported on this blog prior to shipping a release? In the interest of full disclosure, I think that would have been preferable.

    Likewise, why did you take so long to fix it vs Chrome? Google issued a fix for Chrome five days ago! Usually Firefox leads in speed of fix.

  3. Jacob Appelbaum {Tuesday March 22, 2011 @ 10:00 pm}
  4. anon {Tuesday March 22, 2011 @ 10:26 pm}

    Why are we having to blacklist these certificates? Shouldn’t SSL revocation via OCSP/etc. handle this? Does this mean that “proper” SSL revocation basically doesn’t work?

  5. Robert Ransom {Tuesday March 22, 2011 @ 10:27 pm}

    That wasn’t the sort of security problem that should have been kept secret until patches were shipped — it was clear from the beginning that bad guys were already able to exploit the bogus certificates, and keeping the problem secret only guaranteed that users were vulnerable to attack for a longer period of time.

    Who asked Mozilla to keep the fact that a CA (which Mozilla had configured users’ web browsers to trust) had issued fraudulent certificates secret from the intended victims, and why did the Mozilla Foundation and its employees choose to aid ‘cyber-terrorists’ by agreeing to keep the attack secret?

  6. Daniel Colascione {Wednesday March 23, 2011 @ 1:33 am}

    If only we had an automated mechanism that let browsers get a list of blacklisted certificates without the vendors having to release an update — Oh, if only! But we can dream. Let’s hope such futuristic technology is available to our grandchildren.

    Snark aside, OCSP addresses some of the performance and privacy issues surrounding certificate revocation checks, and it’s high time major TLS client implementations support it.

  7. Christoph Anton Mitterer {Wednesday March 23, 2011 @ 4:19 am}

    And once again we see that the concept of a strict hierarchical PKI is completely bollocks (and therefore X.509 too). And that only concepts like OpenPGP’s PKI are really secure.

  8. Giorgio Marinelli {Wednesday March 23, 2011 @ 6:54 am}

    * We Must Fix HTTPS *

    An interesting set of slides on https model: http://web.monkeysphere.info/news/We-Must-Fix-HTTPS/

  9. Gary {Wednesday March 23, 2011 @ 7:51 am}

    @Robert Ransom

    “That wasn’t the sort of security problem that should have been kept secret until patches were shipped”

    It seems that three of the big Browsers had a different opinion, Google, Mozilla, Microsoft were all aware of this issue and were involved to a greater or lesser extent in that approach.

    Read the torproject.org blog post in the link by Jacob…
    “the embargo was to be extended until Wednesday, March 23rd. This extension was ostensibly to ensure that Microsoft would be able to ship their Internet Explorer mitigation pack.”

    Does that torproject blog post agree with your assertion that waiting for patches was the wrong thing to do? Read it and make up your mind.

    On your soapbox final comment:
    Why did the Mozilla Foundation and its employees choose to aid ‘cyber-terrorists’
    Why did the Google and its employees choose to aid ‘cyber-terrorists’
    Why did the Microsoft and its employees choose to aid ‘cyber-terrorists’

    I did not mention Opera so my question to you is, did Opera aid ‘cyber-terrorists’?, and if you believe not, please explain in detail how Opera had a superior approach.

    Repeat the above exercise for Apple Safari.

    The problem of revocation is not an easy area to manage, and in using a given browser (which do you use by the way?), you are putting your trust in the browser provider’s security decisions.

  10. Timothy Brownawell {Wednesday March 23, 2011 @ 7:55 am}

    Maybe try something like http://www.networknotary.org/ ?

  11. Jens Müller {Wednesday March 23, 2011 @ 8:38 am}

    If Firefox ignores errors (like connection errors) on fetching revocation lists etc., then THAT is a bug, and a huge security hole.

  12. Anna {Wednesday March 23, 2011 @ 8:48 am}

    I´m so glad I still use 3.6.15

    *g Anna

  13. Neil Goldman {Wednesday March 23, 2011 @ 3:42 pm}

    @Gary

    Jacob is most certainly critical of the decision to wait on Microsoft’s patches; see his comments on the Mozilla bug tracker: https://bugzilla.mozilla.org/show_bug.cgi?id=643056#c22

  14. nunya {Wednesday March 23, 2011 @ 5:47 pm}

    Setting security.OCSP.require == true causes seamonkey and firefox to not be able to connect to newegg.com

    An error occurred during a connection to cm.newegg.com:443.
    The OCSP server experienced an internal error.
    (Error code: sec_error_ocsp_server_error)

  15. chinese {Wednesday March 23, 2011 @ 7:17 pm}

    Please remove CNNIC ROOT!
    Do you know GFW?
    GFW and CNNIC control by gov!

  16. Daniel Veditz {Wednesday March 23, 2011 @ 8:38 pm}

    nunya: you’ll see such transient errors a lot when you require valid OCSP responses. Either the OCSP server didn’t respond at all, took too long, or returned an error response. Usually hitting the “Try Again” button in the error page will get you in, and since the OCSP response is cached subsequent pages from that site should be fine.
    -dveditz

  17. Danny Moules {Thursday March 24, 2011 @ 12:40 am}

    So this was kept secret for the sake of Microsoft PR? The bug was already exploited and non-duplicable, right? So non-disclosure was reckless and dangerous. What penalty was there in making it publicly known, except equipping people to deal with it? Did we seriously keep it secret to cover another company’s rep?

  18. toko online {Thursday March 24, 2011 @ 2:01 am}

    woow thank you for your info

  19. yksoft1 {Thursday March 24, 2011 @ 2:40 am}

    @chinese: You could just remove references to CNNIC Root (and Entrust.net Secure Server Certification Authority) from mozilla-central/security/nss/lib/ckfw/builtins/certdata.txt, run perl certdata.perl<certdata.txt, and proceed to build your own clean nssckbi.dll for Firefox…

  20. yksoft1 {Thursday March 24, 2011 @ 2:41 am}

    references to CNNIC root are in certdata.txt from nss source..

  21. anon {Thursday March 24, 2011 @ 5:33 am}

    What bugs me is the selective disclosure policy. The arguments in defence of not going with full disclosure don’t strike me as particularly convincing but anyway, why wasn’t Debian (maintainer of “ca-certificates”) or KDE for example notified? And what about Apple?
    Mozilla surely could have forwarded this too if Comodo didn’t bother.

  22. Brandon Sterne {Thursday March 24, 2011 @ 8:46 am}

    @yksoft1:

    You don’t need to rebuild Firefox in order to remove trust for various roots. Go into Preferences > Advanced > Encryption and click on View Certificates to bring up the Certificate Manager. From there you can select a cert and click Edit Trust to remove the trust bits.

  23. Gordon Burditt {Thursday March 24, 2011 @ 10:21 am}

    Is there a way for users to help themselves here (if they care to)? My first reaction on hearing that X issued bogus certificates is to turn off all the preloaded certificates for X immediately. (Ok, I’ll admit this can cause some problems, depending on who certifies the certificates of sites I use regularly). In firefox (3.6.15) I see I can edit “this certificate can identify web sites”, “this certificate can identify mail users”, and “this certificate can identify software makers”, but does turning these off prevent the browser from “this certificate can identify a subordinate CA”? If not, why not?

    I don’t think this kind of problem calls for a delay in dealing with it. With fake certs, you don’t have to worry about going public causing more bad guys to take advantage of the hole (unlike, say, buffer overflow attacks), unless you believe that someone actually generated a fake CA cert and POSTED it, complete with private key.

  24. Juha {Friday March 25, 2011 @ 11:46 am}

    Why the CRL checking for all certificates that have pointer to certificate revocation list is not supported and enabled by default in Firefox? If that were the case, no need to distribute certificate blacklists via software updates. Revocation checking is essential part in correct certificate chain validation, it can not be skipped!

Leave a Comment

  • Comment Policy:Could go here if there's a nagging need Login Instructions: Would go here if there's a desire.