DigiNotar Removal Follow Up

Earlier this week we revoked our trust in the DigiNotar certificate authority from all Mozilla software. This is not a temporary suspension, it is a complete removal from our trusted root program. Complete revocation of trust is a decision we treat with careful consideration, and employ as a last resort.

Three central issues informed our decision:

1) Failure to notify. DigiNotar detected and revoked some of the fraudulent certificates 6 weeks ago without notifying Mozilla. This is particularly troubling since some of the certificates were issued for our own addons.mozilla.org domain.

2) The scope of the breach remains unknown. While we were initially informed by Google that a fraudulent *.google.com certificate had been issued, DigiNotar eventually confirmed that more than 200 certificates had been issued against more than 20 different domains. We now know that the attackers also issued certificates from another of DigiNotar’s intermediate certificates without proper logging. It is therefore impossible for us to know how many fraudulent certificates exist, or which sites are targeted.

3) The attack is not theoretical. We have received multiple reports of these certificates being used in the wild.

Mozilla has a strong history of working with CAs to address shared technical challenges, as well as responding to and containing breaches when they do arise. In an incident earlier this year we worked with Comodo to block a set of mis-issued certificates that were detected, contained, and reported to us immediately. In DigiNotar’s case, by contrast, we have no confidence that the problem had been contained. Furthermore, their failure to notify leaves us deeply concerned about our ability to protect our users from future breaches.

Staat der Nederlanden Certificates

DigiNotar issues certificates as part of the Dutch government’s PKIoverheid (PKIgovernment) program. These certificates are issued from a different DigiNotar-controlled intermediate, and chain up to the Dutch government CA (Staat der Nederlanden). The Dutch government’s Computer Emergency Response Team (GovCERT) indicated that these certificates are issued independently of DigiNotar’s other processes and that, in their assessment, these had not been compromised. The Dutch government therefore requested that we exempt these certificates from the removal of trust, which we agreed to do in our initial security update early this week.

The Dutch government has since audited DigiNotar’s performance and rescinded this assessment. We are now removing the exemption for these certificates, meaning that all DigiNotar certificates will be untrusted by Mozilla products. We understand that other browser vendors are making similar changes. We’re also working with our Dutch localizers and the Bits of Freedom group in the Netherlands to contact individual site operators using affected certificates (based on the EFF’s SSL Observatory data).

The integrity of the SSL system cannot be maintained in secrecy. Incidents like this one demonstrate the need for active, immediate and comprehensive communication between CAs and software vendors to keep our collective users safe online.

Johnathan Nightingale
Director of Firefox Engineering

70 responses

  1. Dave wrote on :

    @Hay: It’s as simple as you think it is. If people don’t install the security updates for their browser, then they won’t get any security updates for their browser. This incident adds to the litany of reasons to scream at people who ignore, or sometimes actively reject, updates.

  2. David Bernier wrote on :

    I support Mozilla’s decision because of
    the risks and potential for trouble if
    nothing were done about DigiNotar-issued
    certificates…

  3. David Bernier wrote on :

    @Hay:

    I think hopefully that either DigiNotar or the
    Dutch government CA can revoke the
    potentially dubious Staat der Nederlanden Certificates.

    As for old browsers, I believe New additional
    root CA certificates can be imported into
    the browser by the user. But it’s a
    highly technical issue, so I’m not sure it’s
    the best idea for people with old browsers;
    it might be better to simply recommend
    upgrading or changing to a up-to-date
    browser & version.

  4. Ingo Kresse wrote on :

    My, my, my, as if it couldn’t get worse: The interim report of Fox-IT (the company investigating in DigiNotar) reveals that all CA servers were in the same windows domain, giving a domain administrator access to _every_ CA server.

    http://www.diginotar.nl/Portals/7/Persberichten/Operation%20Black%20Tulip%20v1.0a.pdf

    They knew that one of their servers could be compromised (since they received a fraudulent certificate issued by them) when they made their press release, stating that their PKIoverheid CA servers were ‘unaffected’.

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

    A horrible thought that we trusted them…

  5. Daniel Veditz wrote on :

    colfer asks:
    > Aside from there being no evidence July 1 is a safe cut-off, can
    > the dates be forged?

    There is -some- evidence that July 1 is OK. Earlier (when we didn’t know about the evidence of hacking in June) July 10 was the earliest discovered certificate. Later it was revealed some hacking was discovered as early as June 17, but with more detailed log forensics it still looks like July 2 was the first cert-issuing attempt and July 10 was the first success.

    Depending on the kind of access dates in certificates can potentially be forged. In the current attack it looks like certificate dates will be reliable, but if the attacker created a signing certificate rather than a server certificate then then they could definitely forge the dates. Current evidence says the attacker didn’t get one of these powerful certs. Then again, the first look missed a whole batch of things so the second might have as well.

  6. Daniel Veditz wrote on :

    @rbdg: You cannot “remove” the built-in certs because they are, well, built-in. If you press the “delete or distrust” button, though, the certificate –IS– marked as untrusted.

    The 6.0.1 update still includes -a- DigiNotar certificate but it is marked as untrusted. For technical reasons it’s better to have an explicit distrust than have it be simply “unknown”.

    Any certificate changes you make (overrides, marking roots as untrusted) are saved in your profile. These changes are NEVER overwritten by an update.

  7. jmdesp wrote on :

    @Daniel : I think it’s a know bug that you can make it appear in the GUI that the cert is no more there, but that it will be, visually, reinstated when you update, maybe as untrusted.

  8. petr_p wrote on :

    @Ramón Antonio: Mozilla overlooks all these national CAs because they are relatively small and because they focus on higher level than Mozilla (Mozilla is interested in commercial web server or MIME usage that is about money only, while national CAs target on qualified usage that puts legal binding replacing hand-written signatures).

    Effectively qualified CAs that demand much higher security standards (e.g. you need to prove you identity in person by showing two state-issued identity cards) are not trusted by Mozilla, whereas CAs that issue certificate just by vague e-email or HTTP challenge/response are trusted by Mozilla. What a sad reality.

  9. gebruiker wrote on :

    in the certificate manager there are still Diginotar Certificate names and what about the problems mentioned here is the the same issue?

    Add Security Exception

    You are about to override how Thunderbird identifies this site.
    Legitimate banks, stores, and other public sites will not ask you to do this.

    Server
    Location: pop3.live.com:995

    Certificate Status
    This site attempts to identify itself with invalid information.

    Wrong Site
    Certificate belongs to a different site, which could indicate an identity theft.

    example:
    http://forums.mozillazine.org/viewtopic.php?f=39&t=2239733&p=10968653

  10. Nima wrote on :

    That’s the first step. We need a new design in security.

  11. brian wrote on :

    I just downloaded the latest version of Mozilla. Diginotar is still a trusted Cert. I had to manually remove them.

  12. David W wrote on :

    @brian – as Daniel Veditz says, the Diginotar roots are still present but are not trusted. This is a *higher* level of security – rather than “I don’t know this root, it may or may not be trustworthy”, this represents “I know this root and do not trust it”.

    If I understand Daniel Veditz’s comments correctly, ‘deleting’ a built in root merely saves an override in the user’s profile that removes all the trust bits on that root. If so, ‘deleting’ the Diginotar roots in Firefox 6.0.2 is a no-op.

  13. Mad Cow wrote on :

    Personally, I don’t understand why I am supposed to trust the majority of the included CA certs. In the main I can work with only one or two of them. I’d really like to distrust all but the few I need to use, but presumably this setting would revert each time I update the software (or at least whenever Mozilla decide to change the trust status of a cert).

    IMO we need to find ways to minimise our dependancy on intermediate organisations like Mozilla to make trust judgements on our behalf. With all respect, this is not their core business. Perhaps an idea for a new plug-in?

  14. Everyone wrote on :

    @Ferdinand – “Well done, giving us a quick and clear resolution.”

    It was neither quick or clear. After all the conversations between the developers Brian and Robert.
    This decision should have been made instantly.
    Instead we got Firefox 6.0.1

  15. amib wrote on :

    Thanks Mozilla for punishing DigiNotar

    Not caring about people security can make big trouble for people in countries like Iran, Syria and some other countries.

    Government is using MITM to steal personal information.

    Please be more sensitive to security
    It’s sometimes related to life of people.

  16. Yield wrote on :

    Peoples might also want to remove this ”trusted” certificat authority from their OS.

    In OS X, this can be done in KeyChains. A simple research for DigiNotar in KeyChains will help you find it. In the ”trust tab” just change the status to ”never trust”

    In Windows, you must use a MMC and add the Certificat SNAP IN, then find DigiNotar and to the same as in OS X… Roughly…

  17. ER wrote on :

    Diginotar is back for me too 🙁
    6 of them listed under certificates in Advanced Tab

  18. shahin wrote on :

    12:26 AM
    9/9/2011
    #################### NEW DigiNotar show on View Certificates !!! ########

    DigiNotar >
    DigiNotar Root CA
    DigiNotar Services 1024 CA
    DigiNotar Cyber CA
    DigiNotar Cyber CA

    DigiNotar B.V. >
    DigiNotar PKIoverheid CA Overheid en Bedrijven
    DigiNotar PKIoverheid CA Organisatie – G2

    Please checccckkkk this Mozillaaaa

  19. sherry wrote on :

    need to get rid of bugs on my laptop its slowing my computer down

  20. Daniel Veditz wrote on :

    shahin, ER, brian:

    Please go to the “About” dialog and confirm you have Firefox 6.0.2 (or 3.6.22). That is the version that contains the fixes.

    In the advanced certificates dialog DigiNotar should show up in the “Servers” tab, not the “Authorities” tab. If you view any of them it should say “Could not verify this certificate for unknown reasons” and the serial number should be 0F:FF:FF:FF (the root one has a lot more FF’s). If you switch to the Details view there should be no checkmarks in the SSL, Mail, or Code columns.

    There may be a DigiNotar root left in the Authorities tab, listed as “Software Security Device” rather than “Built-in Object Token”. That’s a cached copy you can delete if you like, but if you open it it should also say “Could not verify this certificate for unknown reasons” at the top. That wording means it’s an invalid certificate and will not be trusted.

More comments: 1 2 3 4