Why was it important for the diginotar certificates to be blacklisted?

Benefits for LWN subscribers

The primary benefit from subscribing to LWN is helping to keep us publishing, but, beyond that, subscribers get immediate access to all site content and access to a number of extra site features. Please sign up today!

By Jake Edge
September 7, 2011

The more we hear about the DigiNotar certificate situation, the worse it seems to get. What started out looking something like the Comodo incident from last March—a serious breach in its own right—has now turned into damning evidence of almost unimaginably lax security at the DigiNotar certificate authority (CA). That led browser makers to do something unprecedented: not to just blacklist the known-bad certificates that had been issued, but to blacklist any DigiNotar-issued certificate. As it turns out, that was the right response (modulo a short-lived whitelisting of some Dutch government certificates) as the scope of the compromise has just continued to grow.

The certificates in question are SSL/TLS certificates that are used to authenticate and deliver the keys used to encrypt HTTPS traffic. CAs issue certificates for secure web sites and sign them with their own private keys so that browsers can ensure that the certificates are valid. The public half of those CA keys are stored in a browser's "root store". When they decide to include a given CA's root key, browser makers are explicitly trusting certificates signed by those CAs. In the wrong hands, a certificate signed by a trusted root can be easily used to perform man-in-the-middle attacks against users who are accessing the secure site.

Compromise and discovery

The compromise of DigiNotar's certificate signing systems evidently occurred on or before July 19 and once the CA detected the problem, it issued revocations for the certificates that it was able to determine were wrongly issued. DigiNotar evidently did not notify browser makers or others of the compromise and essentially swept the whole thing under the rug. But the attackers, who may have compromised parts of DigiNotar's systems as far back as May 2009, were able to issue certificates that were not detected when the compromise was uncovered.

One of those fake certificates, for *.google.com, was reported to the Gmail help forum by a user in Iran. The user was able to do so because of a Chrome/Chromium browser feature called public key pinning. Essentially, Chrome has a list of the hashes of public keys that are allowed to be used to sign certificates for Google's servers. If one of those public keys is not found in the certificate presented, it is a fatal error, which is what the user observed.

It is fortunate for that user—and now the rest of the internet—that Chrome has that feature. Without it, browsers like Firefox, IE, Safari, and others happily accept the bogus certificate. The evidence seems to point to an effort emanating from Iran—likely sponsored or run by the Iranian government—to generate and then use these certificates for man-in-the-middle attacks against Iranians, particularly those who might be involved in protests or other dissent. The evident link to Iran is one that both the Comodo and DigiNotar attacks share.

Dutch government sites

Once the problem was reported, Google then alerted other browser makers who were generally quick to issue updates (though Safari seems to have lagged) that removed the DigiNotar root certificates from the root store, effectively blacklisting all DigiNotar-issued certificates. There is a wrinkle, however, because some Dutch government sites use certificates that are signed by DigiNotar (which is a Dutch company). A blanket ban of DigiNotar-signed certificates would have affected these sites, so, at the request of the Dutch government, an exemption to the ban was added for Firefox and Chrome. As a Mozilla blog update puts it:

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.

But it seems that the government was a bit hasty in that assessment, because it was fairly quickly revoked. Mozilla described it this way in the update: "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." In fact, since then, the Dutch government has taken over operational management of DigiNotar, and explicitly "denounces trust in certificates issued by DigiNotar".

This is ugly stuff. The CA model relies on trust and part of that trust is that CAs will zealously guard access to their signing authority. In two recent cases—and it is certainly possible there are other compromises as yet unknown—we have seen that some CAs are not taking enough precautions. As it stands, every time another compromise is discovered, browser makers will have to race around to patch their browsers, then Linux distributions need to get updates out (for Firefox and others), and, finally, users actually need to apply the update.

Unfortunately, it is not just a Google certificate that is out there in the wild. Early reports were that it was just a handful of bad certificates, but as time went on, the number of certificates issued by the attackers using the DigiNotar keys have risen: first to around 200 and now there are reports of as many as 500. Not only were its signing systems compromised, but it would seem that DigiNotar's logging and audit procedures were circumvented as well.

A pastebin posting purporting to be from the attacker (of both DigiNotar and the Comodo affiliate back in March) sheds some light on the extent and motives for the attack. It also indicates that there are four other CAs that have been penetrated, including one that is named: GlobalSign. Since that posting, GlobalSign has, at least temporarily, stopped issuing certificates. Whether that's just based on prudence or whether GlobalSign found evidence of a compromise is unclear. If the pastebin posting is real, however, there are other CAs that are also at risk.

Going forward

For obvious reasons, this recent spate of attacks has raised the profile of the problems inherent in the centralized CA model that is in use today. The central authorities are supposed to reduce the attack surface against SSL/TLS keys, but that depends on the vigilance of those CAs. The number of different CAs trusted by a modern browser is rather eye-opening, and hoping that they will all keep their systems secure is pretty clearly forlorn.

Small CAs, like DigiNotar, can be blacklisted when—if—compromises are discovered, but that's much harder to do for large CAs like Comodo or Verisign, for example. Luckily, detecting bad certificates is relatively easy—easier than figuring out if CAs have been compromised. Since web sites must present their certificate each time an encrypted connection is made, both detection and evidence gathering are fairly straightforward. Chrome's "pinning" feature does that in a limited way, though it still places trust in the CAs that do have signing authority for Google's keys; should any of those CAs be compromised, pinning would not catch them.

The pinning feature is one that other browsers will likely consider adding. Google has made it clear that it will allow other sites to pin their certificates to specific CA keys, and presumably any other browsers that implement it will do the same. However, that may turn Google, Mozilla, and others into the de facto arbiters of certificate authenticity, which may not be a desirable outcome. It is also possible that Chrome and the other browsers could provide a way for sites to do their own pinning via HTTP Strict Transport Security (HSTS) or some other means.

But, other alternatives to the centralized model are certainly being looked at. One that seems to have attracted some attention recently is Moxie Marlinspike's Convergence, which uses "trust notaries" in place of hard-coded lists of CA root keys. These notaries are in multiple locations and compare notes on the certificates that get presented to them, which is an effective way to recognize a certificate-based man-in-the-middle attack. Convergence is a Firefox add-on that is based on ideas from the Perspectives project, along with some of Marlinspike's ideas on trust agility.

We will certainly see more problems with compromised CAs down the road, particularly because governments have shown an interest in acquiring "fake" certificates—and using them against their citizens. It's a problem that is not going away soon and one that needs to be addressed. Building webs of trust implicitly via Convergence/Perspectives or more explicitly using something like Monkeysphere is one possible solution, or piece of a solution. Removing or reducing the trust that we currently place in CAs is pretty much required to be part of any solution, but we've known that for quite some time now. The CAs may not like it, but their stranglehold over the issuance of trusted certificates is likely on its way out.

(Log in to post comments)

New versions of Chrome and Firefox have been released today by Google and Mozilla due to the discovery of a rogue Google SSL certificate being abused in the wild.

DigiNotar has admitted yesterday that the issuing of the certificate in question was missed by the auditing firm that went through its systems following the breach it experienced in July, and that many other rogue certificates were issued by the attackers but have been recalled in the meantime.

But, the fact that it declined to share for which particular sites these certificates were issued likely made Google hard code 247 additional SSL certificates for non-Google domains into the blacklist of an upcoming Chrome version, reports The Register.

In the meantime, The Netherland’s government issued a statement saying that the public key infrastructure system used by the government has not been compromised.

DigiNotar has also confirmed that the root server that is used to generate DigID certificates – digital identities used to access the majority of online services offered by Dutch government agencies – has not been accessed by the attackers.

Given that DigiNotar made this claim on account of the results of the poorly effected audit that managed to miss the rogue Google certificate, a lot of people are understandably skeptical, says ThreatPost.

If there is one positive consequence of this whole incident, it is that the security community has begun raising its voice against the (obviously) fallible digital identity certificate system that is currently in place, and has begun searching for alternatives.