Fraudulent *.google.com Certificate

Johnathan Nightingale

65

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.

  21. Mark wrote on :

    Diginotar/Vasco published an official statement:
    http://www.vasco.com/company/press_room/news_archive/2011/news_diginotar_reports_security_incident.aspx

  22. Peter Breur wrote on :

    I am becoming very afraid if it is this easy to kill a company that has served the Dutch community for a very long time. More so, a lot of bonafide Dutch companies and government agencies use server certificates from DigiNotar. So your action will affect a whole nation.

    Also, if I remember correctly, no such harsh measures were taken against Comodo, who(se subsidiaries) experienced similar security breaches several times in the not so distant past. One wonders if this is a trust or a fear issue (DigiNotar is probably not large enough to start law-suits against the browser builders).

    I.m.o. browser builders are stepping out of line if they are acting as if they are the root CA’s for the planet Earth. They could play an important role in educating their users, instead of nurturing them.

    Peter Breur (Dutch citizen)

  23. Jeroen van Gelderen wrote on :

    @Peter Breur

    Two wrongs don’t make a right. Comodo should have been killed and so should Diginotar. The fact that Mozilla didn’t do the right thing w.r.t. Comodo doesn’t mean they should make the same mistake with Diginotar.

    The facts as admitted by VASCO/Diginotar in today’s press release are even more damning:

    According to today’s VASCO press release DigiNotar discovered a compromise of MULTIPLE certificates on *July* 19th 2011. They did NOT issue a press release then and attempted to quietly revoke the certificates leaving unwitting users exposed.

    It would seem that Diginotar/VASCO got caught 5 weeks later only because they failed to revoke the fraudulent *.google.com certificate at that time despite what is presumably two audits (internal and external).

    —-8<—-8<—-8<—-8<—-8<—-

    OAKBROOK TERRACE, Illinois and ZURICH, Switzerland – August 30, 2011 – VASCO Data Security International, Inc. (Nasdaq: VDSI; http://www.vasco.com) today comments on DigiNotar’s reported security incident. DigiNotar is a wholly owned subsidiary of VASCO.
    On July 19th 2011, DigiNotar detected an intrusion into its Certificate Authority (CA) infrastructure, which resulted in the fraudulent issuance of public key certificate requests for a number of domains, including Google.com.
    Once it detected the intrusion, DigiNotar has acted in accordance with all relevant rules and procedures.
    At that time, an external security audit concluded that all fraudulently issued certificates were revoked. Recently, it was discovered that at least one fraudulent certificate had not been revoked at the time. After being notified by Dutch government organization Govcert, DigiNotar took immediate action and revoked the fraudulent certificate.

    The attack was targeted solely at DigiNotar's Certificate Authority infrastructure for issuing SSL and EVSSL certificates. No other certificate types were issued or compromised. DigiNotar stresses the fact that the vast majority of its business, including his Dutch government business (PKIOverheid) was completely unaffected by the attack.

    [...]

  24. Frox wrote on :

    see: http://www.vasco.com/company/press_room/news_archive/2011/news_diginotar_reports_security_incident.aspx

    The very important fact not being explained here is that (IIUC) they found the intrusion on july 19th and revoked several fraudulent certificates. BUT they failed to revoke one of them (the *.google.com one, again IIUC)

    What I mean is thatthey found an intrusion that created fraudulent certificates (BAD) and their subsequent audit failed to spot the google one (VERY BAD). Don’t they know if they are issuing certs for google or not?

  25. Sahand wrote on :

    Thank you guys for taking care of us :)

    You would probably be happy with killing DigiNotar for good if you were in my shoes. It will teach other CA’s to take security measures seriously.

    For you guys, a fake certificate means a stolen password or personal information. For me and thousands of other Iranians, it leads to jail, torture or even death sentence.

    Is the reputation and income of a faulty IT company which cannot protect its own assets, worth more than the lives and goodness of a nation?

  26. christian baier wrote on :

    i am glad diginotar is being deleted. just think the same should have happened with comodo…

  27. Pedram wrote on :

    hmmmmmmm
    Why when i Delete or Distrust.. the Diginotar Root and Click ok then when i come go back to Tools Options and … Its Again in there ? :O
    no matter how many time i Delete or Distrust it its still there :(

    i was using Google yesterday too when Suddenly it Stop Working and Give that Alert about Revoked certification

  28. Alastair Mayer wrote on ::

    It’s not Mozilla’s (or Google’s, or Debian’s) action that’s killing (if it does) DigiNotar. DigiNotar effectively committed corporate suicide by issuing a fraudulent cert in the first place.

    Similar measures probably should have been taken against Comodo; DigiNotar is in the unfortunate position of having triggered a response to the situation that Comodo sensitized the community to (to use an analogy from allergic responses). However, without such a response this time, the CAs would likely take validation even less seriously. Actions have consequences, people and corporations would do well to remember this.

  29. Ed wrote on :

    @Peter Breur:

    A significant difference (and not the only one) in the Comodo case, is the fact that it did not take 40 days for the fraudulent certificate to be spotted – which is quite frankly appalling on DigiNotar’s part!

  30. Brian Miller wrote on :

    @Peter Breur

    The difference between the two incidents is that Comodo discovered the invalidly issued certificates with internal auditing and then took steps to correct the problem. Diginotar didn’t find their own invalidly issued certificates and only revoked them once they were brought to their attention by a third party. See here: http://www.mozilla.org/projects/security/certs/policy/MaintenancePolicy.html

  31. PhoenixMylo wrote on :

    It should be noted that Comodo also caught the breach within hours, immediately revoked all the affected certificates, notified both the browser vendors and the affected parties immediately and of their own accord. They screwed up, but they didn’t try to hide the fact as Diginotar did. It’s too bad that Diginotar did not follow their example, or the example of Startcom recently in suspending all certificate services and thoroughly going through systems to make sure that all fraudulent certificates were caught and systems were secure before resuming business.

  32. Christoph Anton Mitterer wrote on :

    I really wonder why you remove DigiCert (Europe based) now while you didn’t remove Comodo (US based)…

    Also why do you still refuse to implement RFC 5081? OpenPGP is in contrast to the forcibly strict hierarchical model (which OpenPGP would support, too, btw) the only real solution for security.
    A strict hierarchical model will always fail with things like this one, sooner or later.

  33. Marceau GUIHARD wrote on :

    When I delete Digi Notar CA, it is recreated immediately.

    FF 6, Windows 7 64bits.

  34. Lode V wrote on :

    @Peter Breur

    Jeroen van Gelderen is right imo

    IMO not only the DIGINOTAR Root CA should be revoked but also all other by the Diginotar signed certificates should be blocked too.
    The Breach Of Trust does not stop at only the Root CA.

    DIGINOTAR/VASCO is now playing victim.
    DigiNotar is the certificate authority for the government of the Netherlands’ public key infrastructure (PKIoverheid) and identity management platform DigiD,

    The fact that DIGINOTAR/VASCO discovered a compromise of MULTIPLE certificates on *July* 19th 2011 and that they did NOT issue a press release then and attempted to quietly revoke the certificates leaving unwitting users exposed, means to me as a dutch citizen that I do not trust anymore the certificates for the government of the Netherlands’ public key infrastructure (PKIoverheid) and the identity management platform DigiD.

    These, by the Diginotar signed certificates, should be blocked too.

  35. Lode V wrote on :

    Below a list of DigiNotar Root structure from their website in dutch:
    from
    http://www.diginotar.nl/Klantenservice/Rootcertificaten/tabid/308/Default.aspx

    Overview of rootcertificates
    - – - – -
    Overzicht actuele rootcertificaten

    Hieronder een overzicht van de DigiNotar Root structuur. Via de tabs kunt u de rootcertificaten downloaden.

    DigiNotar Root CA
    DigiNotar Public CA
    DigiNotar Qualified CA
    DigiNotar Services CA
    DigiNotar Private CA´s
    DigiNotar SSL Root
    DigiNotar Root CA
    DigiNotar Services CA
    DigiNotar EVSSL
    DigiNotar Root CA
    DigiNotar Extended Validation CA
    PKIOverheid Root G2
    Staat der Nederlanden Root CA – G2
    Staat der Nederlanden Organisatie CA – G2
    DigiNotar PKIoverheid CA Organisatie – G2
    DigiNotar Root CA G2
    - – - – - –

    Reading
    https://bugzilla.mozilla.org/show_bug.cgi?id=682956#c16
    and
    https://bugzilla.mozilla.org/show_bug.cgi?id=682956#c17
    I understand Mozilla does not distrust all rootcertificates handled by DigiNotar.

    For some reason Mozilla will only distrust rootcertificates which contain
    the text: DigiNotar Root CA
    Mozilla appears to trust the rootcertificates handled by DigiNotar for the Dutch Government: PKIOverheid / Staat der Nederlanden

    Why thinks Mozilla that Rootcertificates handled by DigiNotar for the Dutch Government are more to be trusted than other Rootcertificates handled by DigiNotar ?

    ALL Rootcertificates ARE EQUAL
    BUT SOME Rootcertificates ARE MORE EQUAL THAN OTHERS.

  36. Pirolet wrote on :

    Et en français ?
    Pas de possibilités sur cette page à laquelle j’ai eu accès par le site “Le Monde.fr”.

  37. bardia67m wrote on :

    @Marceau GUIHARD @mohammad from Iran @bahareh
    There is no concern. If you distrust or delete the certificate it will be marked as untrusted even if it shows up again. you can make sure by clicking “Edit Trust” and seeing that all of 3 trust scopes are unchecked. In this case that CA cannot be used anymore!

  38. Kasperl wrote on :

    As Lode V asked, why is Mozilla still trusting the Dutch government certificate? Is this because audits have proven that the certificate is handled differently? Or is it because it would cause too much trouble for Dutch citizens to get SSL warnings on the digitial identity service provided by the State? If it’s the latter, it seems rather dangerous, since that SSL cert is used to encrypt a lot of sensitive user data, including passport numbers, account details, and benefit statements.

    1. Daniel Veditz wrote on :

      The Dutch government, the owner of the Staat der Nederlanden roots, asked that we not revoke their certs. We currently have no evidence of a problem with those certificates and assurances from the Dutch government and GovCERT that issuance through those intermediates is under their control and has not been compromised. Like you I have my doubts, but they are bringing in an outside company to perform a technical audit so we will wait and see what the results are.

  39. Mark wrote on :

    If you are an Opera user, you automaticlly get protected, no update needed. Opera deals with revokation and blocked revokation, and has an online blacklist of Root CA’s

    http://my.opera.com/securitygroup/blog/2011/08/30/when-certificate-authorities-are-hacked-2

  40. Ferry wrote on :

    Please don’t fall for our government (NL) and still accept the DigiD. Getting a new cert doesn’t cost that much (especially for a government) and only takes some time and a bit of labour. Kill the DigiD cert as well. Maybe it will wake up our government that still claims (retarded as they are) they completely trust Diginotar.

    Our government shows time and time again they don’t understand *shit* about IT whatsoever.

  41. SteveL wrote on :

    The big issue here is not so much punishment as this fact: nobody knows how many other certificates were issued off the DigiNotar root CA. They haven’t disclosed which ones were issued and revoked -and they clearly don’t know which certificates were issued. Currently, the only way to defend against any other rogue certificates is to block DigiNotar.

    Once more details become clear it may be possible to block all certs issued within a specific time period, but right now the overreaction is the safest action.

  42. pmhparis wrote on :

    Mozilla should NOT be silently adding cert auths silently the way they have been doing over the past few years. At a minimum we should be given a one time option “do you wish to vett every new cert auth?” on upgrades so that we can refuse such aberrations as chungwa telecom. I have banking clients that have more than enough problems with fishing attacks from china without having to worry about MITM attachs from a root auth they never wanted in the first place.

    Also, I see no reason why the hard coded root certs show up again after a relaunch once the user takes the time to go into the options & remove them. Give an option to reset certs to default values if you want to help those that get into trouble by over deleting. The current setup is leading to a crisis in confidence in all the Mozilla tools among those who take security into account when which browsers are validated for use by governmental & company employees.

  43. joao wrote on :

    Or you can simply do, like I did some time ago, on advice by Steven Gibson (if I’m not in error) and delete/ not trust the certificate authorities that I don’t need (in Firefox)… most times, I do need the one’s from Verisign, Thawte, Comodo, Multicert-CA 02 (sub from GTE CyberTrust Global Root), Digicert (just for the facebook)… and that’s it! I would like to remove Comodo, but to many web site use Comodo, so I do need them. And I can also enable selectively the roots for does sites I visit and really want to access.
    In doubt I would at least delete all from Turkish, Hong Kong post office, china ones, any from government’s (unless you need them), Wells Fargo… not even their web site uses it’s root lol!

  44. Lode V wrote on :

    Does someone know where I can download or find lists of Certificates
    I know there is a Microsoft Certificate Trust List (CTL)

    @Kasperl
    Good question, still unanswered by Mozilla.

    As a Dutch Citizen I do not worry about some trouble getting SSL warnings on the digitial identity service provided by the State?
    I do worry about possible (other unreported) security breaches inside the Dignotar company which affect the security and Trust of the rootcertificates handled by DigiNotar for the Dutch Government: PKIOverheid / Staat der Nederlanden.

    The Digid is used to verify the identity of Dutch citizens on the Internet.
    The system has been mandatory when submitting tax forms electronically.
    So as a Dutch citizen I’m more or less obliged to use the use the digid.nl which uses these rootcertificates handled by DigiNotar for the Dutch Government: PKIOverheid / Staat der Nederlanden.

    I would like the Dutch government to use another CA and create NEW certificates for PKIOverheid / Staat der Nederlanden.

  45. Christoph Anton Mitterer wrote on :

    btw: Would you also remove Verisign when they were hacked?

  46. Ken B wrote on :

    Christoph – *Please note the CA of this topic is DigiNotar and Not DigiCert. Not the same CA.

  47. TrvsT wrote on :

    @joao yeah, you’ll want to keep DigiCert in your root store as they’re the cert for facebook and yahoo. Definitely not the same as DigiNotar.

  48. kasperl wrote on :

    Re Daniel Veditz:
    The assurances come indirectly from Diginotar itself, there has been no direct verification of anything yet according to Dutch news sites. As the Digid is still used for tax purposes and benefits, why are you believing the company who had the breach on this certificate, and not on all the other, less important ones? The Staat der Nederlanden is basically saying they don’t want to bother to change all the certs.

    Re Lode V:
    I’m also Dutch, and share the same worries.

  49. Private Joe wrote on :

    Actually I believe that in Google case Diginotar either knew what it was doing – and did get “sufficient” compensation for the upcoming trouble or it was done by some of its employees working for iranian secret service.

  50. James wrote on :

    There’s no indication in all of this (probably due to a lack of disclosure by DigiNotar) that anything has been done about the fraudulent certificate for Mozilla that DigiNotar also issued.

    Also, according to F-Secure (http://www.f-secure.com/weblog/archives/00002228.html) DigiNotar’s site has been hacked for over 2 years.

    Finally, the URL for the revocation list (.crl) that DigiNotar gave in 2007 when they were approved by Mozilla as a CA is incorrect. That .crl has not been updated for months (not since February).

    All in all this breach of trust is an order of magnitude larger than Comodo’s.

More comments:1 2