Mozilla Security Blog
Categories: CA Program Firefox Security

Firefox Blocking Fraudulent Certificates

Johnathan Nightingale

27 responses

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.

27 comments on “Firefox Blocking Fraudulent Certificates”

  1. dilip wrote on

    unfortunate this happens around the Firefox 4 release

  2. Bob wrote on

    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 wrote on

    I’ve written an analysis of this for the Tor blog: https://blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusion

  4. anon wrote on

    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 wrote on

    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 wrote on

    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 wrote on

    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 wrote on

    * We Must Fix HTTPS *

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

  9. Gary wrote on

    @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 wrote on

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

  11. Jens Müller wrote on

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

  12. Anna wrote on

    I´m so glad I still use 3.6.15

    *g Anna

  13. Neil Goldman wrote on

    @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 wrote on

    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)

    1. Daniel Veditz wrote on

      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

  15. chinese wrote on

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

  16. Danny Moules wrote on

    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?

  17. toko online wrote on

    woow thank you for your info

  18. yksoft1 wrote on

    @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…

    1. Brandon Sterne wrote on

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

  19. yksoft1 wrote on

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

  20. anon wrote on

    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.

  21. Gordon Burditt wrote on

    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.

  22. Juha wrote on

    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!

  23. none wrote on

    Is it because the HTML 5 or it is just my thought?

  24. ThomasB wrote on

    Strangely it took longer for firefox developers to fix this bug than for chrome creators. Nevertheless i still prefer mozilla, but i totally agree that this bug shouldn’t be kept a secret until the patches were released.

  25. Pixelflo wrote on

    One of my friend got scammed using an older version of firefox – can’t remember which version though.

    He though it was secure and trustworthy site as is had a SSL certificate.

    These security updates are a great news. Any Security enhancements are always welcome.