Improving visibility into CA operation with Certificate Transparency
We believe strongly in the need for transport layer security (TLS) on the modern web. We also know that security is a process, and not an end state, and regularly update our TLS configuration to meet best practices as they evolve. As a regular part of this process, we monitor new and exciting developments in the TLS (and its historic counterpart, SSL) ecosystem to evaluate how they can fit into Fastly’s TLS deployment. One such development is the Certificate Transparency project.
If you follow the security news cycle, you may have seen recent discussions about Google detecting a Certificate Authority (CA) in China improperly issuing certificates capable of transparently (that is, without warning) imitating Google TLS-protected websites. As part of the subsequent investigation, Google removed the implicated CA from the list of trusted CAs and indicated that in order for the CA to be considered for re-inclusion, they would have to implement a system known as Certificate Transparency (CT). Below, I’ll outline the basics of CT and how it relates to this and other CA-related incidents in recent history.
What is Certificate Transparency?
Certificate Transparency is a relatively new initiative backed by Google, supported by an IETF working group and codified in an evolving RFC standard (RFC 6962) that aims to bring increased visibility into the operation of trusted CAs and the issuance of the X509 certificates used in TLS. The goal is to use this increased visibility to more easily and quickly detect when certificates are improperly issued as a result of CA negligence, error, or compromise.
The need for transparency
If CAs are trusted entities by design, why is CT necessary at all? Recall that in the TLS public key infrastructure (PKI) any trusted CA is equivalently capable of issuing a certificate for any subject identity. That is, just because https://www.fastly.com uses a certificate issued and vetted by DigiCert, your browser would equivalently accept a certificate issued by any other trusted CA, of which there are hundreds.
Even more troubling, a CA can delegate its ability to issue certificates to another party, known as an intermediate CA, and any of these intermediate CAs are equivalently capable of creating trusted certificates for any subject identity. Presently there is no way to track how many such intermediates exist other than through experimental observation, i.e. connecting to TLS-protected websites and noting which CAs and intermediates are contained in the chain of presented certificates. Unfortunately this observation process only provides a lower bound on the number of intermediates that exist and not a complete picture.
Every CA and intermediate can equivalently issue certificates, so in order for an adversary to perform transparent man-in-the-middle (MITM) attacks against a Fastly property, they don’t need to compromise or otherwise trick DigiCert, the CA for https://www.fastly.com, but any CA. This reduces the strength of the TLS PKI to the weakest CA/intermediate. While initially this may seem like a minor issue, it is far from a theoretic concern; in the past few years, we have seen numerous cases of CAs incorrectly issuing certificates for subjects that did not request or otherwise endorse their creation. Historically it took upwards of weeks to detect these compromises in the wild and react accordingly.
The components of CT: logs, monitors, and auditing
Certificate Transparency improves this situation by having participating CAs advertise the issuance of new certificates into a public log. Parties interested in detecting certificates issued for their identity without their knowledge or consent can monitor the CT logs, decreasing the time to detection and enabling more proactive response. Further, logs can be audited to ensure they are playing fairly and are not themselves compromised. These three components — logs, monitors, and auditors — form the basis of CT.
Image credit: Certificate-Transparency.com
The design of CT includes a number of controls meant to increase the security and integrity of the overall system. Perhaps most importantly, the logs are constructed such that they are an append-only structure. That is, new certificates can be added to the log but they cannot be removed or edited without immediate detection. Internally, the logs are a merkle tree structure that allows the log operator to provide cryptographic proof that the log is consistent. The merkle tree design allows for the CT operator to produce a Signed Tree Head (STH) that can be used to quickly verify the whole tree is in a consistent (unmodified) state. A more detailed introduction to merkle trees and the STH verification is provided on the Certificate Transparency website. The log system also provides strong proof that when a certificate is submitted to the log, it will be included within a maximum amount of time — the merge window. The certificate inclusion proof takes the form of a signed certificate timestamp (SCT). Logs communicate to one another through a gossip protocol to ensure they all share a common view of the CT ecosystem.
The proof that a certificate is included within the log (the SCT) can be delivered to clients in a number of ways. The three methods of delivering the SCT defined today are: as part of the OCSP staple, as an option within the X509 certificate itself, or as part of the TLS handshake. As CT becomes commonplace, web browsers and other TLS clients can then enforce that for a certificate to be trusted it must prove it is in a CT log and therefore detectable if it were mis-issued.
Certificate Transparency today
Several logs are active today, and are being run by entities including Google, DigiCert, and independent volunteers. The auditing mechanisms built into CT ensure that all of the logs play fairly and are not presenting an edited view of the log to serve a nefarious purpose, reducing the amount of blind trust clients must place in individual CT logs. Chrome is moving towards requiring CT proofs for Extra Validation (EV) certs to be considered trusted. As the RFCs related to CT move through the process of becoming standards, more browsers will begin to require CT proofs, resulting in greater transparency and security for the whole TLS ecosystem.
Both of the CAs Fastly uses to provision certificates (DigiCert and GlobalSign) have endorsed CT and have indicated their intention to participate. This means customers using our shared certificate and shared wildcard certificate services will receive the benefits of CT without any additional work — our CA will automatically include these certificates in the relevant CT logs.
