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
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
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
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.
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,
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
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
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
to post comments)