September 2, 2016
Certificate authority (in)security is in the news again, with the recent revelation of several security vulnerabilities and other serious oversights at the WoSign certificate authority. The Mozilla community is currently debating what sanctions should be taken against WoSign. While we wait for Mozilla and other browser vendors to make their decisions, I thought it would be interesting to explore what sanctions other certificate authorities have faced in the past.
Note that this post will focus on sanctions imposed by Mozilla and Google, since they discuss certificate authorities more openly than other browser vendors.
2011: Comodo avoids consequences for reseller compromise
Although security researchers had discovered flaws in certificate authorities prior to 2011, the first serious compromise occurred in 2011 when a Comodo reseller was breached and used to issue unauthorized, publicly-trusted certificates for high profile domains such as google.com, mozilla.org, and skype.com. Although Comodo themselves were not breached, at the time Comodo trusted their resellers to perform domain control validation, meaning a compromised reseller could cause the issuance of publicly-trusted certificates for arbitrary domains.
Since Comodo weren't breached, they were able to detect and contain the compromise quickly, which likely helped them avoid sanctions. They remain widely trusted to this day, but no longer allow resellers to perform domain control validation.
2011: Death penalty for DigiNotar
Not long after the Comodo reseller compromise, a much more serious compromise occurred that remains the most serious certificate authority incident to date, and which resulted in the most severe sanctions possible. DigiNotar, a Dutch certificate authority, was totally compromised. Over 500 unauthorized certificates were detected and a rogue wildcard certificate for google.com used for mass interception of Internet traffic in Iran. Since DigiNotar was so thoroughly compromised, the full extent of the breach was never known.
2012: Amnesty for MITM certificates
In 2012, Trustwave disclosed that they had willfully issued an intermediate CA certificate to a company for the express purpose of signing unauthorized, publicly-trusted certificates to intercept and inspect encrypted traffic.
Although the certificates issued by this intermediate CA were clearly not authorized by domain owners, there was some concern that this practice was neither clearly prohibited nor uncommon, and that it would be unfair to punish the first CA to admit to it. After a public discussion, Mozilla opted for an amnesty policy instead of sanctioning Trustwave. Certificate authorities were explicitly informed that this practice was forbidden and given two months to comply or face sanctions.
2013: No green bar for TURKTRUST
In 2013, Google learned that TURKTRUST had "mistakenly" issued two intermediate CA certificates to subscribers instead of regular certificates, and that one of them had been used to sign a rogue certificate for google.com. TURKTRUST provided a plausible explanation for their mistake and there was no indication that they had been compromised. Google decided to revoke TURKTRUST's ability to issue extended validation certificates, and Mozilla temporarily suspended the inclusion of a new TURKTRUST root certificate. No further action was taken, making this a fairly mild sanction.
2013 - 2014: Regional death penalty for ANSSI and India CCA
In 2013, ANSSI, a French certificate authority, was caught doing what was expressly prohibited after the Trustwave revelation: they issued an intermediate CA that was used to intercept and inspect encrypted traffic. Google and Mozilla responded by "name constraining" ANSSI so that it could only issue certificates for domain names ending in .fr or one of the other top-level domains used by French territories. Although this sanction fell short of a full death penalty, it killed off ANSSI for most of the world.
In 2014, an intermediate certificate authority signed by India CCA was compromised and used to issue rogue certificates for Google and Yahoo. After investigating the compromise, India CCA found only four rogue certificates. However, Google was aware of additional rogue certificates that India CCA did not detect and concluded that India CCA was unaware of the full scope of the breach. Consequentially, they decided to name constrain India CCA to a small set of Indian domains.
2015: Suspension of CNNIC
In 2015, Google learned that CNNIC, like ANSSI and Trustwave, had issued an intermediate certificate authority that was used to intercept encrypted traffic. CNNIC did this in violation of their own Certificate Practice Statement, which said that they would not issue intermediate certificate authorities to external organizations. In response, both Google and Mozilla revoked trust in new CNNIC certificates.
Since existing certificates remained trusted, this was a less severe sanction than DigiNotar faced. To implement this sanction, Chrome and Firefox embedded a whitelist containing the hash of every existing CNNIC certificate. Since there were only a couple thousand CNNIC certificates, this was practical.
Google welcomed CNNIC to reapply for inclusion, but stipulated that all CNNIC certificates would have to be logged to Certificate Transparency logs. Unlike DigiNotar, CNNIC remains operational.
2015: Certificate Transparency required for Symantec
In 2015, Google discovered that Symantec had issued over 100 publicly-trusted "test" certificates for 76 different domains, including google.com, without the authorization of domain owners. In response, Google announced that all Symantec certificates issued on or after June 1, 2016 would have to be logged to Certificate Transparency logs. Chrome 53, released this week, enforces this requirement and rejects any unlogged Symantec certificate with an issuance (a.k.a. notBefore) date on or after June 1, 2016.
2016: What will WoSign face?
As we can see from the above, every certificate authority incident was different and therefore merited a different response. Would any of the above sanctions work with WoSign?
Death penalty, like DigiNotar: Although WoSign has not been compromised like DigiNotar was, they have displayed a shocking amount of sloppiness for an organization entrusted to sign certificates for any domain on the Internet, which arguably warrants distrust. However, there are over 100,000 unexpired WoSign certificates in existence. Distrusting WoSign would cause any site using one of these certificates to break, which risks desensitizing people to security warnings. Does the security benefit from distrusting WoSign outweigh this risk?
Revoking extended validation status, like TURKTRUST: Is this a strong enough sanction for WoSign's failures?
Name constraining, like ANNSI: Since WoSign has issued certificates worldwide, there is no set of name constraints that could be meaningfully applied to WoSign.
Suspension, like CNNIC: Could new WoSign certificates be distrusted, but existing certificates grandfathered? Unfortunately, since there are over 100,000 unexpired WoSign certificates, it would be impractical to include a whitelist in browsers as was done with CNNIC. And since WoSign has been caught backdating certificates, it would be imprudent to rely on the notBefore date to decide if an existing certificate should be grandfathered.
Require Certificate Transparency, like Symantec: WoSign has already promised to log all certificates issued after July 5, 2016 to Certificate Transparency logs and has asked browsers to block certificates issued after this date that are not logged. But how can a browser really know if a certificate was issued after July 5, 2016 or not? WoSign can't be trusted to set the notBefore date faithfully, and there are too many existing certificates to embed a whitelist in the browser.
If you're worried about certificate authorities like WoSign issuing certificates for your domains, you should check out Cert Spotter, a service to monitor Certificate Transparency logs for unauthorized certificates. Available as open source or a hosted service.