Trust in the Era of Hackable Certificate Authorities

June 2nd, 2016 by Rupinder Gill

The Internet is rapidly embracing end-to-end SSL/TLS security. The NSA surveillance leaks in 2013 kick-started the “encrypt everything” movement, and now Internet giants (Google, Yahoo, Facebook, Twitter, etc.,) are all offering their services over SSL/TLS. In addition, collaborative projects – such as cacert.org and Let’s Encrypt – and open source orchestration and lifecycle management tools are being developed to help manage SSL/TLS certificates better, (e.g. Netflix’s Lemur.)

Current Web Trust Model

At the core of SSL/TLS protection is Certificate Authorities (CAs). CAs are trusted third parties that issue and validate certificates and serve as root of trust for these certificates.  Browsers and client applications trust root CAs and verify a SSL/TLS certificate presented to them by chaining them up to one of the trusted CAs. Most browsers maintain a whitelist of CAs they trust, which is called the “root certificate store”. Given the importance of CAs in the trust relationship between web servers and clients/browsers, the security and trustworthiness of CA entities is paramount. Browsers apply restrictions on which CAs gets listed into their “root certificate store” and they all require CAs to pass a WebTrust audited assurance process. All these steps are taken to ensure credibility and security of the CAs.

Known Compromises and Misuses

In the current trust model, CAs are treated with absolute trust. But this approach is seriously broken. Despite the efforts mentioned above, CAs have been compromised and have been known to engage in non-trustworthy actions on multiple occasions. For example:

  • In March 2011, Comodo CA was hacked and a number of fraudulent certificates were issued under Comodo’s authority. Same year Dutch CA DigiNotar was also compromised to issue a large number of fraudulent certificates.
  • In Dec 2012, Google found that a number of fraudulent certificates were issued by an intermediate CA linking back to TURKTRUST, a Turkish CA.
  • In April 2015, China’s CNNIC, got blocked from the root certificate store of Chrome and Firefox following an incident where an Egypt-based intermediate CA operating under the authority of CNNIC issued a number of certificates for Google domains. It was found the intermediate CA had no documented PKI practices and no oversight into how the CA private key was stored or controlled.
  • In May 2015, Symantec got in trouble with Google for issuing a number of unauthorized certificates for Google domains. Symantec claimed that these were generated for internal testing purposes only and never fell in wrong hands. However, Symantec had to fire a number of employees involved and conduct a review of its processes to issue certificates.
  • Just recently, in May 2016, Symantec and Blue Coat ended up in news when it was claimed that Blue Coat had been made an intermediate CA under root CA of Symantec. This was considered of particular concern since Blue Coat products are used for snooping SSL/TLS traffic. Potentially Blue Coat could issue certificates for any domain for snooping. Symantec and Blue Coat maintain that the private key was always with Symantec, and intermediate CA was only used for internal testing. Given Symantec’s earlier row with Google over fraudulent certificates and claims that Blue Coast’s SSL/TLS snooping products have been used by repressive regimes, (such as Burma, Iran and Syria), Symantec/Blue Coat’s explanation raises understandable suspicion and skepticism.
  • Besides privately operated CAs, there have also been reports where Government sponsored compromises of the trust chain have also been conducted.  In December 2013, Google discovered that an intermediate CA linking back to ANSSI, a French CA had issued fraudulent certificates for a number of Google domains.  The Dutch CA DigiNotar compromise in 2011 was used to issue fraudulent certificates for a large number of domains and these certificates were reportedly used to snoop SSL/TLS traffic of large number web users in Iran.

I could go on and on with many other examples, but I believe these documented scenarios make my point.

Trust Model is broken: What is being done?

The long list of known compromises and misuses raise serious questions about the corporate responsibility of these CAs. It is also evident that it is very hard to place absolute trust in any external CA. A single security compromise, procedural oversight, policy violation or pressure from a government body could possibly force a CA to act in a manner that breaks the entire trust model and issue fraudulent certificates and/or introduce untrustworthy intermediates in the trust chain.

This gaping hole in the trust model has not gone unnoticed and attempts have been made to replace the absolute trust in CAs with a more distributed trust model. Notable projects are:

  • Convergence: a Firefox Add-on that lets browser use a number of distributed notaries as trust anchors rather than a hardcoded list of CAs.
  • Google Certificate Transparency Project: a certificate transparency project to detect misbehaving CAs and fraudulent certificates by making all certificates publicly available. The Certificate Transparency (CT) framework is open and public.

Certificate Transparency requires all SSL/TLS certificates to be publicly recorded in a Certificate Log, which offers users a way to look up all of the digital certificates that have been issued for a given domain name. Google is currently running a Certificate Transparency log where certificates can be looked up by hostname. List of other running logs is available from Google (DigiCert and Symantec are two well-known CAs participating and maintaining a Certificate Log).

This project has a comprehensive and promising approach; however this project is in initial stages of formalization and deployment.

Segmented Trust Model

With the current state of the web trust model, where absolute trust in third party CAs is not perfectly secure, and misuse detection frameworks are not mature enough, both clients and web applications need to be vigilant about:

  • Which CAs are being trusted
  • How much trust is being extended to those CAs

On the web application side, operators need to consider using segmented trust architecture rather than a flat approach. Trust segmentation refers to using different trust anchors for different trust requirements/functions. These trust anchors can be public or private, based on whether the trust boundary needs to be established for internal or external components.  Segmentation protects against scenarios where compromise of one-trust anchor results in compromise of the entire trust architecture.

In the web application world, traditionally SSL/TLS certificates have only been used for securing front-end server connections with untrusted users. Typically these certificates are obtained from a popular third party public CA. This is a popular choice since browsers already have popular CAs in their “root certificate store”. Hence browsers can easily verify the certificate presented by the web application.

However, the recommended practice is to secure even backend machine-to-machine communications using mutually authenticated SSL/TLS.  Certificates need to be deployed on backend machines so that they can mutually authenticate each other and encrypt all traffic between them.

Before obtaining SSL/TLS certificates from a third party CA, web application operators should consider employing segmented trust measures such as using a private trust anchor for securing internal components. Using a private CA would help create security boundary around internal components, which will not be impacted by compromise or misuse of any external third party CA and vice-versa.  Using a private CA does not mean immunity from attacks, however by using trust segmentation, collateral damage can certainly be contained and might also prove to be more cost effective in the long run.

Open source projects such as pki.io, EJBCA and cfssl, are being developed to help run a full-fledged private PKI infrastructure for more sophisticated operators. Hardware Security Modules (HSMs) can be used for secure crypto key generation, usage and storage. Services such as cloudhsm are making HSMs available to web applications in the cloud as well.

Depending on the web application architecture, multiple private CA trust anchors can be established and used to manage trust between different groups of internal components. Such architecture would further limit the damage a compromised CA or fraudulent certificate can have on the entire trust architecture of the web application.

If using private CAs is not an option, the same effect can be achieved by creating trust segments using different third party CAs. This is essentially a defense-in-depth measure to protect against compromise of a single CA.

Conclusion

Currently, we have little choice but to use third party CAs for establishing trust between completely unrelated entities such as browsers/clients and web-applications.  However, logically related entities that have some pre-established administrative relationship such as backend systems of a web application can use a more segmented trust model by using private trust anchors. Using multiple private trust anchors for certain components and public trust anchors for other more public components can help segment and contain any fallout from a compromised or misbehaving CA and/or a fraudulent certificate. If using private CAs is impractical, trust segmentation can also be achieved by restricting different components groups to use different third party CAs as trust roots.

As monitoring frameworks such as Google’s Certificate Transparency Project mature, these frameworks can help detect misuse in both public and private CAs. Until then, the best approach is to be vigilant.