plus/minus epsilon

Certificate Transparency (CT) is a relatively new addition to the TLS ecosystem. Its fundamental goal is to provide the tools for website operators to detect the mis-issuance of certificates for their own websites. Historically, this is something that only large tech companies have been able to do successfully.

CT is an improvement over a previous, now deprecated, technology called HTTP Public Key Pinning (HPKP). HPKP prevents most certificate mis-issuance outright by letting servers send a whitelist of valid certificates for themselves. In the future, browsers will refuse to connect to the server if it offers a certificate that wasn't on the whitelist.

HPKP was never widely adopted because it was difficult to deploy and misconfigurations would often take people's websites down. Since CT is a reporting mechanism, rather than a prevention mechanism, browsers and Certificate Authorities (CAs) have been able to deploy it fully without any action from website operators.

Technically, CT was implemented by having multiple organizations setup public, append-only logs. When a publicly-trusted CA issues a new certificate, it submits information about the certificate to a subset of these logs and receives a signed promise from each log that this information will be published. These signed promises (called SCTs) are incorporated into the final certificate given to the website operator. When the certificate is served by a web server, browsers can validate the SCTs and get some assurance that there's a public record of the certificate.

Of course, a log can issue SCTs without actually publishing the information they promised to, and this could allow a mis-issued certificate to go undetected. However, getting an undetectable mis-issued certificate would require a compromised CA to collude with (or compromise) a third-party log operator.

To better appreciate the trade-offs made in the design of CT, you can consider other ways the system could've been built. For example, instead of having CAs submit certificates to logs before issuing them, you could have browsers simply report the certificates they see to an endpoint run by the browser developer. The benefits of doing it this way is that it would have full coverage of certificates that have already been issued (unlike CT) and it can be deployed by the browser unilaterally, without any changes needed from CAs or the creation of a community of log operators. The downsides are that the repository would require a significant amount of resources to run, and a network-level adversary capable of deploying a mis-issued certificate would also likely be able to block a user's access to the reporting endpoint.

Alternatively, some type of blockchain could be used to create a global append-only ledger of all certificates that have been issued, and this blockchain would replace log operators. This would definitely provide a higher level of security than CT does, by requiring a 51% attack instead of collusion between a small number of trusted parties. Like the previous approach, it would also not require the creation and maintenance of a community of log operators. However, the maintenance of a blockchain would likely require just as much work and have a considerably higher total economic cost depending on the consensus algorithm.

Fig. Comparison of Certificate Transparency with alternative  solutions.