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.)
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.
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:
I could go on and on with many other examples, but I believe these documented scenarios make my point.
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:
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.
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:
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.
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.