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 comments on “DigiNotar Removal Follow Up”

  1. Michichael wrote on

    A well made point. Realistically, 90% of people just click “ignore” anyway when they encounter a certificate error, but the rest of us might get suspicious when we see bad certs. The entire system needs to be re-evaluated, but that can’t happen when there are bad root CA’s.

  2. Ferdinand wrote on

    Well done, giving us a quick and clear resolution. As it turned out this was one useless CA. The Dutch government has some things left to clarify to its citizens.

    I hope Mozilla will consider the possible implications beyond the immediate scope of Diginotar. This episode really puts a dent in the chain of trust.

  3. ocrete wrote on

    Knowing that these certificates are actively bad, would it be possible to make Firefox refuse to load any site that uses them? And not even give the user the option to accept it, I saw that you do that on expired certs now.

  4. biscuit town wrote on

    Everyone has known that SSL has been broken for years because of how “trust” is managed in browsers nowadays but, as usual, nobody cares until we are certain someone has already been screwed.

  5. d2 wrote on

    Bravo, Jonathan. SSL needs to have something other than lowest price guiding corporate purchase decisions, and while there’ll be backsplatter from any firm stuck with DigiNotar, this NEEDS to be done.

    2 thoughts:

    — What about Comodo? Did I miss your revocation of their CA? If not, WHY not?

    — Is Moxie’s notary mechanism ( Convergence ) or CMU’s (Perspectives?) on your radar for Firefox?

  6. Daniel Veditz wrote on

    The sad thing is you can’t even blame race-to-the-bottom pricing in this case, the DigiNotar certs were about a thousand euros.

    I’m intrigued by the Perspectives/Convergence experiments and we’re definitely watching to see how they work in practice and at scale. We have no plans to build either one into Firefox at this time.

  7. ldpreload wrote on

    d2: Comodo made an honest mistake and handled it well. Revoking it out of retribution would do nothing — Comodo is one of the few CAs we know to be able to handle mistakes well! We have no idea whether most of the CAs have made mistakes, let alone how they would handle it. (As the current incident shows, “poorly” is a good guess.)

    Comodo is also a sufficiently big player that permanently revoking it would yield a lot of individual employees moving elsewhere in the industry. Since ultimately all failures are human, that would just decrease accountability.

    And finally, revoking Comodo’s CA would just teach CAs that, no matter how well they recover, they’re in trouble if a mistakeis public, so better to just never publicize mistakes.

  8. Gervase Markham wrote on

    ocrete: the block is non-overridable for certificates issued after the 1st of July 2011.

  9. Fredrick Rybarczyk wrote on

    DNSSEC? Love, @fredrick_r

  10. Doublehypocrite wrote on

    You still have trust comodo. Why?

  11. Martin wrote on

    Michichael, there is no technical prohibition against working on parallel infrastructures for modelling trust on the web, including the well-known ultimately flawed, unlimited limitless trust CA anchor model. Start coding 😉

  12. Ramón Antonio wrote on

    Don’t know what is the policy to select CA but here in Spain we are always missing the Fabrica Nacional de Moneda y Timbre (Spanish Royal Mint) as a CA. It issues certificates for all governmental websites and personal/company certificates. We always have to add it manually for electronic proceedings and most users don’t know how to do it.

  13. anonymous wrote on

    Comodo immediately reported the incident. It seems DigiNotar didn’t.

  14. SteveL wrote on

    Can’t we have a way of blocking all Certs issued within a date range? So we could block Diginotar’s certs from July 1 until Dec 31 (i.e. not until somebody else had audited the system and felt it was secure). Then people like Comodo and other too-big-to-fail CAs could be partially blocked as punishment for issuing any invalid certificates

  15. alex wrote on

    I’ll admit a definite ignorance about CA’s and such, but I’m curious as to why CRL’s aren’t more fully employed here. Isn’t a CRL a list of revoked certificates that the browser can check and then set appropriate trust attributes based on any certs listed? Had DigiNotar issued a CRL for the bad certs and the browser had it stored in the cert database, would this not be sufficient to warn users that they are accessing a site using one of the bogus certs? And where does OSCP fit in? I’ve got it enabled, but would it even help in this case?

    It just seems ludicrous that users have to update their applications with a hardcoded blacklist of cert’s and CA’s everytime there is a compromise to the SSL system published in the news.

  16. Ken Dawber wrote on

    Judge, Jury and Executioner.

    Millions of people died in various wars to stop this type of thing happening. The issue isn’t whether DigiNotar did the the right thing or not. It is that we cannot have a judge, jury and executioner all as the same organization and all of this without fair trial and due process etc.

    The fact that mozilla can act as all three shows something very wrong with the process.

    This is particularly important in this case as there are large numbers of innocent third parties who have certificates from DigiNotar. One person is accused of doing something wrong so we go kill kill kill anybody and everybody associated with them.

    Due process should have external parties acting as judge and jury.

    In the period that was required to set this up, there obviously needs to be some safeguards but I doubt if the kill of the full root in needed for that. Since the issue here is DigiNotar’s competence as a root, a minimum needed is to try to allow another competent authority take temporary control while the issue is being sorted.

  17. Jasem wrote on

    I should say even after installing 6.0.1 update and restarting the browser, I noticed that DigiNotar still exists in Certificate Manager. I don’t know why but I had to delete it manually.

  18. jmdesp wrote on

    @Martin : It’s definitively not about coding. It’s all in conceiving a trust model that really handles failure better. For this, it’d be good to realize that inventing a completely new format is not really required, it means a lot of library rewriting for little gain, the part of “I devise new tools” is a strong diversion from the actual aim. If you’re smart you can keep the X509 format and completely change the trust model and it helps you focus on changes that truly alter the trust model.

    The systems based on distributed trust seem to me to be the nearer from really adding something new and significant, but they rise some serious anonymity issues.
    Google’s CA pinning has now demonstrated that it actually brings something useful, and I think Mozilla should very seriously think about integrating it.

  19. Blah wrote on

    ldpreload, d2:
    IIRC, Comodo did not simply make a mistake and then correct it… rather, Comodo wrongfully issued a cert for a Mozilla domain, claimed to have corrected what allowed the wrongful issuance to occur, and then much later wrongfully issued certs again. The wrongful issuance would have been prevented had Comodo made the corrections it claimed it made the first time around.

    Comodo’s roots should be permanently yanked.

  20. muddybulldog wrote on

    It’s not about punishing, it’s about preserving the system as best as possible. Comodo made efforts to work with those impacted and the browser vendors to get their mistake rectified. As was pointed out, punishing registrars is just going to cause coverups making things worse, not better.

More comments:1 2 3 4