Blog

Update (17 March 2022): A year later, Chrome is about to deploy the next iteration of its CT policy. With this change, which will become active on 15 April 2022, Chrome will no longer require that certificates are recorded in at least one Google-operated CT log. Read more about this change in our new blog post.

Certificate Transparency (CT) continues to develop and improve at a good pace. A new feature called SCT Auditing has been in development for some time and is currently being deployed to Chrome. The auditing will provide better visibility into the correct operation of the CT ecosystem.

Why Do We Need Auditing?

To understand what SCT auditing is and why it's necessary, we need to take a few steps back and first understand what we want to accomplish in the first place. Clearly, with CT, the main goal is to have all public certificates recorded in CT logs, where they can be audited and monitored. Today, we have a system in place that does that, but we're still lacking technical means to ensure that is genuinely happening.

The vast majority of Certification Authorities (CAs) generate certificates that include Signed Certificate Timestamps (SCTs), which are proofs of logging to CT logs. Before a certificate can be issued, CAs communicate to CT logs information about their intention [to issue the certificate] and receive SCTs in return. The SCTs are then embedded in certificates, where they can be checked by browsers. On the surface, it seems that all is well, but this system works only if you trust the CT log operators. Looking at a certificate and its SCTs, browsers can't actually tell if the certificate had been logged; instead, they can only verify the endorsements from the CT logs, which is not the same. After all, a SCT, which is simply a digital signature, could be created without the certificate actually being published. So, in a sense, a SCT is a promise.

This is not to say that breaking the CT we have today is easy. It's not. But, in theory at least, a CA and two CT log operators could collude to produce a certificate with SCTs that's not actually public. Obviously, fewer entities would be needed if the CA also operated one of the CT logs. There are also other attack vectors to consider, for example if all the entities resided in the same country or could otherwise be legally compelled to do the wrong thing. Software security issues could also serve as an entry point; developing CT log software is not easy and most logs run the same codebase. A single critical vulnerability could be used to compromise several logs.

All of the above is a major reason for why Chrome's CT policy requires that at least one of the SCTs comes from a CT log operated by Google. With this requirement Google ensure that have a copy of every single CT certificate in their own database. Additionally, the same requirement ensures minimum log operator diversity, with SCTs guaranteed to come from at least two entities. Of course, having a requirement like that simplifies things for Google, but it's unhealthy otherwise. At this time, Google is a single point of failure for the entire Web PKI. Further, Google may trust itself, but that doesn't mean that the rest of the world trusts Google. In other words, we need a mechanism that doesn't require trust. Enter SCT auditing.

What is SCT Auditing?

The concept of SCT auditing is simple: a certain amount of SCTs encountered in the wild are checked to ensure that the certificates they refer to actually exist in the CT logs.

In practice, it's more complicated. Direct auditing (by browsers) is not entirely feasible, for example because CT logs aren't designed to receive huge amounts of traffic. Instead, someone needs to build the infrastructure for auditing via a proxy, and they also need to devise a way to make the system work without compromising users' privacy. That's what Google have been working on. At CT Days last year they said that some results will be available in 2021, and we're now seeing results of their efforts.

The privacy issues haven't yet been solved, so SCT auditing will initially be enabled only for the users who are already sharing information with Google. According to Google, SCT auditing will open a path for Chrome's CT policy to remove the requirement to always use one CT log belonging to Google.

We should celebrate this next step, as it marks a significant milestone in the evolution of CT, making it technically independent of Google. That said, we shouldn't forget that CT continues to exist on the back of a significant investment from Google and that true independence requires that other stakeholders step up and share the workload.

Thanks to Emily Stark for her insights and comments on this blog post prior to publication.