Blog
Welcome to the Hardenize blog. This is where we will document our journey as we make the Internet a more secure place and have some fun and excitement along the way.
Update (16 Dec 2020): Updated some of the links to follow moved resources.
Update (13 Oct 2020): Google's Devon O'Brien has written a summary of CT Days 2020 providing additional detail to some of the topics covered below. Rasmus Dahlberg also has a write-up.
Trust in the WebPKI is now easier than it was ten years ago. We have gone from a world where attacks against individual CAs can compromise the entire system without trace to a world where multitudes protect our trust. Much of this is thanks to Certificate Transparency (CT), a system that ensures that all public certificates are recorded in tamper-resistant storage.
Chrome started requiring CT for Extended Validation certificates in 2015. Since then, some 3.3 billion certificates have been logged to 35 currently usable logs. In 2018, Chrome started to require CT for all public certificates, with Apple joining them by the end of the same year. It's therefore now been almost two years that we have been able to keep track of all public certificates, making the entire ecosystem much safer.
With billions of issued certificates, it is not sufficient to just mandate logging of public certificates to CT logs. CT embeds a verification system that enables clients to validate that certificates had been published.
CT logs provide so-called Signed Certificate Timestamps (SCTs) when certificate (or pre-certificate) chains are added to the log. An SCT is a cryptographic proof that the log operator has seen the certificate and an assurance that the certificate will be added to the log within a specified period of time. Multiple SCTs issued by different CT logs are needed for a certificate to be trusted.
There is also a twist. To bootstrap an immature system, Google injected themselves in the mix with an additional requirement that at least one SCT must come from the CT logs they operate. In doing this, Google created a single point of failure for the entire WebPKI—if their CT logs are not available, no certificates can be issued. The problem is not just theoretical; in November 2018 there was an outage of some Google logs that disrupted certificate issuance globally.
Since the beginning, Google have been explicit in their desire to eliminate this single point of failure. Part of the responsibility for resolving the reliance on Google services falls outside of Google. The CT ecosystem requires enough maturity and diversity so that it can operate independently and yet safely. Others have stepped up: There are now 5 independent CT Logs operators (Cloudflare, DigiCert, Let’s Encrypt, Sectigo and TrustAsia). There is an independent browser implementation too, with Apple’s Safari requiring CT for all certificates issued after 15th October 2018. Support for CT is being added to client libraries as well. Things are shaping up, but we're not there yet.
A lot of effort goes into maintaining the CT ecosystem. CT operators, browser vendors, CAs, and other interested parties gather once a year to discuss progress and plan future improvements. The most recent gathering was CT Days 2020, which was held on September 8-9. The focus on reducing reliance on Google was a key theme this year. Both Apple and Google joined the event with new policies to discuss.
Apple’s recently revised CT policy is now divergent from Google’s. Among other changes, the new policy requires that certificates with a lifetime of over 6 months issued after 1st April 2021 must have at least 3 SCTs from two different log operators. This change should strengthen the CT guarantees, providing evidence of diversity.
Google’s new policy explicitly restricts the scope to cover Chrome, rather than the open source Chromium project and its consumers. The idea behind this is that adopting a client policy requires thought and should not be done lightly.
These policy developments from Apple and Google ensure that there is now debate around the development and implementation of the standard with the prospect of more voices in future since embedders of Chromium (Microsoft Edge, for example) will need to define their own policies.
The Chrome CT folks also used CT Days to announce some improvements in the resources available to CT Log operators. CT Log operators provide a vital component of the trust provided by the CT ecosystem; more logs across organisations, jurisdictions and implementations mean more confidence in the system as a whole.
A newly announced Chrome CT site features a revised CT Log policy, as well as information on the CT Log application process. Google’s changes to their CT Log policy will make it easier for other organisations to operate their own logs; for example, all new CT logs must be temporarily sharded (split into different time periods) rather than single, monolithic logs that are difficult to maintain and even more difficult to retire.
CT Log operators must demonstrate compliance to the relevant standards (RFC6962) as well as good log availability. Google engineers gave an overview of Monologue, the tooling used for log monitoring and explained the monitoring criteria.
Attendees also discussed the creation of CT Logs specifically for CA certificates; currently, information on a chain is only submitted once an end-entity is logged. Transparency of intermediate certificates (especially those not currently disclosed) would be welcome.
Finally, Google attendees also discussed what barriers remain to removing Google as a hardcoded entity in the CT requirements. They listed three conditions:
CT has come a long way. Everyone is benefiting from the transparency CT added to the PKI ecosystem. Users benefit because their interaction with CT is no longer via a single browser enforcing a single policy. Log operators benefit because the application processes and policies are clearer and better documented. CAs benefit because there are more logs and better metrics, and that essentially pushes them to do a better job.
As it's still early days, more work is needed. Some big players have been silent on their plans to adopt CT, in particular the other major browser vendors such as Mozilla and Microsoft. We also need more independent CT logs, for example those managed by CAs.
Google as a single point of failure remains a concern, but we need to make further improvements before they will accept to remove themselves from the loop. The path toward that seems somewhat clear: more diversity and CT log operators, followed by more stable policies. In other words, keep moving.