Fraudulent *.google.com Certificate

Update (Sept. 6, 2011 @10:37 a.m. PT):

New security updates for Firefox are now available.

Update (8.30.11 @ 11:25 p.m. PT)

Mozilla just released an update to Firefox for Desktop, Thunderbird and SeaMonkey. Updates are now available for:
•    Firefox for Windows, Mac and Linux (final release)
•    Firefox for Windows, Mac and Linux (3.6.21 final release)
•    Firefox Aurora for Windows, Mac and Linux
•    Firefox Nightly for Windows, Mac and Linux
•    SeaMonkey (2.3.2)
•    Thunderbird (6.0.1)

We strongly recommend that all users upgrade to these releases.

If you already have Firefox, you will receive an automated update notification within 24 to 48 hours. Users can also manually check for updates if they do not want to wait for the automatic update.

New versions of Firefox for Mobile (final release and Beta), Firefox Beta for Desktop and Thunderbird will be released shortly.

Issue

Mozilla was informed today about the issuance of at least one fraudulent SSL certificate for public websites belonging to Google, Inc. This is not a Firefox-specific issue, and the certificate has now been revoked by its issuer, DigiNotar. This should protect most users.

Impact to users

Users on a compromised network could be directed to sites using a fraudulent certificate 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. We have received reports of these certificates being used in the wild.

Status

Because the extent of the mis-issuance is not clear, we are releasing new versions of Firefox for desktop (3.6.21, 6.0.1, 7, 8, and 9) and mobile (6.0.1, 7, 8, and 9), Thunderbird (3.1.13, and 6.0.1) and SeaMonkey (2.3.2) shortly that will revoke trust in the DigiNotar root and protect users from this attack. We encourage all users to keep their software up-to-date by regularly applying security updates. Users can also manually disable the DigiNotar root through the Firefox preferences.

Credit

This issue was reported to us by Google, Inc.

 

Johnathan Nightingale
Director of Firefox Development

 

65 responses

  1. Jacob Appelbaum wrote on :

    Thank you for setting a very positive example by revoking the trust of DigiNotar’s root!

    I hope all other browsers take note, follow your exemplary lead and that all other CAs take note as well. If a CA gets owned this badly, they should not be considered authoritative any longer. This is a great action and it directly protects users!

    It’s going to be painful for all of Holland for a while. Still, this is almost certainly the least painful path overall. The Iranians who have been targeted for MITM with this CA root’s certs almost certainly face serious physical violence, torture and worse.

    Thanks to the Mozilla and Google team for detecting, disclosing and taking action!

  2. Robert wrote on :

    Finally god measures are being taken, removing trust to CA authorities with bad security record. I ask why the previous incident at the time of 4.0 the CA was not punished the same way?

  3. Oliver Lavery wrote on :

    “the certificate has now been revoked by its issuer, DigiNotar. This should protect most users.” Really? Isn’t that just a wee bit overstated? Most users who never use WiFi, or a network that’s shared with other users … maybe…

    Kudos on promptly killing the root CA, tho’.

  4. Annoyed user wrote on :

    How many disasters like this one we’ll have to endure before people realize the current trust model for SSL is absolutely broken?

    I just went through the built-in root certs that ship with Firefox. There are well over 50. The majority of them I’ve never heard of. Some of them I’d definitely not trust.

    What is the inclusion criteria on that list anyway?

    Also I assume you wouldn’t get a warning even if you visited Google before and the cert magically changed to the point of using a different root, right? Sigh.

    By the way the fake cert was issued over a month ago.

  5. Daniel Cheng wrote on :

    Killing a CA for revoking a cert?
    Sure the next CA will try to cover their fault better.

  6. Boris wrote on :

    > What is the inclusion criteria on that list anyway?

    They’re described at http://www.mozilla.org/projects/security/certs/policy/

  7. Benjamin Franz wrote on :

    “Killing a CA for revoking a cert?”

    No. Killing them for *issuing* a fraudulent one that has global impact in the first place. The only reason CA’s exist *at all* is to prevent precisely what happened. If they are incapable of providing *valid* Certification Authority, they should not be a CA. Because that is what CA’s are supposed to do.

  8. Boris wrote on :

    > Killing a CA for revoking a cert?

    No, killing a CA for not telling anyone about the breach when they found out about it (as well as generally being incommunicado about what, if anything, they know about the scope of the problem, what steps they’re taking to address it, etc).

  9. Greg Price wrote on :

    @Daniel Cheng: That would indeed be frightening. Fortunately the revocation was just the CA’s response after the issue was already public (and they don’t seem to have learned about it until it was.) The issue was originally detected by an alert user seeing a warning in Chrome, not by the CA.

    See the original report:
    http://www.google.co.uk/support/forum/p/gmail/thread?tid=2da6158b094b225a

  10. Andrew Drake wrote on :

    The CA can’t cover it up — if a fraudulent certificate is found (by anybody!), it is irrefutable proof that the CA is compromised or otherwise untrustworthy. In this case, Google found and reported it, but anyone could.

  11. caf wrote on :

    Daniel Cheng: The fradulent certificate wasn’t discovered by the CA revoking it, it was discovered by a MITM target (http://pastebin.com/ff7Yg663)

  12. Dan Applegate wrote on :

    @Daniel Cheng

    > Killing a CA for revoking a cert?
    > Sure the next CA will try to cover their fault better.

    DigiNotar is not taking a (deserved) beating for revoking the compromised certificate. They did the right thing in revoking it, and that action probably saved as much of their shredded reputation as anything else they could have done.

    The real problem here is that they never should have been put in a position where they had to revoke a fraudulent certificate which they had issued. They failed because they didn’t vet the issuant anywhere close to as much as they should have.

    Further, even if someone made an honest mistake, or if the company was duped despite their thorough background check (upon which they stake their reputation, and around which they base their entire business), the appropriate response is not to “cover their fault” as you suggest. If that’s what happened with DigiNotar, and they tried to cover their tracks before anyone noticed, they deserve to fail as a business of trust. Rather, the only way for a trustworthy company to maintain that trust in light of such a mishap is for that company to IMMEDIATELY revoke the certificate and make an announcement, not have one of your clients like Google beat you to the punch.

    DigiNotar’s impending downfall is no one’s fault but DigiNotar’s.

  13. Daniel Veditz wrote on :

    Google has a statement as well: http://googleonlinesecurity.blogspot.com/2011/08/update-on-attempted-man-in-middle.html

  14. lynX wrote on :

    What about Comodo, GeoTrust, GlobalSign, QuoVadis, RSA WebTrust and StartCom? As long as they will sell you an intermediate signing authority for money, any of those can be used for MITM purposes. Luckily my Certificate Patrol will tell me if anyone tries that on me…

  15. mohammad from Iran wrote on :

    I deleted it and updated my firefox. but it again appears in the list!
    what should I do?

  16. Matteo Panella wrote on :

    @Daniel Cheng
    > Killing a CA for revoking a cert?

    Not quite: Mozilla (and Google, and Debian…) are killing a CA for issuing a fraudulent certificate (lack of security), failing to detect and revoke the fraudulent cert in their db until it was discovered in the wild (lack of audit) and most importantly failing to provide any detail on what the hell happened (lack of trust).

    Oh, and also because they issue EV certs, so the severity of each reason should be doubled.

  17. person287 wrote on :

    That’s seems like a pretty monumental mess up. If you are going to be a certificate authority then these sorts of things simply shouldn’t happen.

  18. fish_ wrote on :

    Will only the Root CA be revoked or are all the Diginotar signed certificates blocked too?

  19. bahareh wrote on :

    i have problem with deleting that certificate…when i delete it it came back quickly …i dont know how to fix this problem

  20. Delete’em All wrote on :

    Inclusion criteria include:
    “””
    We require that all CAs whose certificates are distributed with our software products:

    * provide some service relevant to typical users of our software products;
    “””

    OK, how was that Turkish certificate relevant to a typical user of Mozilla? And the Hungarian one?

    It is not your job to be inclusive in this context; quite the opposite – it’s your job to be exclusive.

More comments:1 2 3 4