10.4 Rogue CAs

If a CA is compromised, it will issue certificates for web servers with a fake identity, and impersonation attacks are the consequence, breaking entity authentication within TLS. The most serious incident of this kind goes by the name of Operation Black Tulip: In July 2011, an attacker took control of the Dutch CA DigiNotar (for more details, see Section 19.5.2 in Chapter 19, Attacks on Cryptography) and issued fraudulent certificates for *.google.com and other important domains [199].

The main target of the attack seemed to be 300,000 Iranian Gmail users, who lost their credentials for various Google services, including Google Mail and Google Docs due to the attack. The real source of the attack was never disclosed. Initially, many signs pointed toward the Iranian government, but later on, the well-known security researcher Bruce Schneier also blamed the NSA [41].

How should we deal with a rogue CA, especially the certificates issued by it? Of course, a CA compromise is a valid reason for certificate revocation, but we can neither trust a CRL nor an OCSP response signed by a rogue CA. Moreover, in most cases, we cannot rely on some independent, higher-order CA to revoke the certificate of the rogue CA. There is, however, a list of trusted CAs within modern browsers (see Figure 10.6), and indeed, trust in the DigiNotar CA was withdrawn by all major browsers by September 2011.

Figure 10.6: List of trusted CAs within Firefox

This example shows that the major browser manufacturers do have the potential to act like some global root CA. In 2015, Mozilla introduced OneCRL, where CA certificate revocation information is gathered centrally, then pushed out to client browsers on an almost daily basis. For this, all available CRLs are crawled, and revoked CA certificates as well as revoked high-profile end entity certificates, which may have a large impact on Firefox users, are included. Moreover, following a security incident such as Black Tulip, CA certificates may be entered manually into OneCRL [60]. Google’s Chrome browser uses a similar mechanism known as CRLSets. The basic idea behind both OneCRL and CRLSets is to concentrate on CA certificates to reduce the size of the lists and to rely on OCSP stapling for end entity certificates.

Another promising innovative initiative from browser manufacturers is called CRLite [108]. CRLite aims to include all revoked certificates and is currently being tested by Mozilla [89]. In CRLite, the browsers locally store certificate revocation information in a compressed form that needs only a few megabytes of storage. The browser downloads daily updates, taking up storage space in the order of kilobytes. Most importantly, these lists can be held locally, so that no privacy issues arise from checking the status of a certificate.