TLS Certificate Transparency is about improving the (web) TLS ecology

October 22, 2022

In Emily M. Stark's Certificate Transparency is really not a replacement for key pinning, one thing that Stark notes is that Certificate Transparency doesn't really have strong security properties. You can say some fuzzy things about security properties that CT perhaps offers (although they get fuzzier when you look at the details), but there's very few concrete security claims you can make (or that people try to make, for example in RFC 9162). Having been thinking about this for a while, I think that Stark is correct here, and that Certificate Transparency is not about security as much as it is about improving the 'Web PKI' ecology

Certificate Transparency has unquestionably improved the TLS ecology in general. Concretely, people have used CT logs to detect problematic TLS certificates, ones with various sorts of bad field values and so on. More broadly, requiring Certificate Authorities to log their issued certificates to CT logs has pushed CAs away from bad practices, because they know those practices will now be visible (or they will be in violation of browser requirements). It may have contributed to CAs being more willing to close down subordinate CA signing certificates (since those will now be more visible). And people certainly use CT logs to scan for (probably) miss-issued certificates for domains of interest (which can have multiple causes).

Further, Certificate Transparency has raised the costs of advanced attacks for powerful attackers, because it's vastly increased the chances that the first use of a compromised or suborned CA will be the last use. In the pre CT days, you could quietly get a TLS certificate for 'facebook.com' from a CA and have some chance of hiding this unless you made wide-scale use of it. Today, this is impossible; Chrome (the dominant browser) won't accept a TLS certificate without endorsements from multiple CT logs, and that makes it very likely that your 'facebook.com' TLS certificate will appear in those logs, be spotted, and trigger alarms.

All of this has vastly improved the public TLS ecology. It's not all roses (attackers reportedly scan CT logs for new hosts to probe, for example, and internal hosts with valid TLS certificates are much more visible), but it's much better than it used to be. But, as Stark covers, Certificate Transparency doesn't offer lots to the individual host or domain, especially a small one, especially if you don't want to (or can't) sign up for a real time monitoring system. And as Stark also covers, if you do detect that there's a mis-issued TLS certificate for your domain, there's not necessarily much you can do about it.

The other way to put this is to say that Certificate Transparency is more about holding Certificate Authorities to account than it is about directly improving the security of any individual website. Holding CAs to account is critical for the overall security of all TLS sites, but it doesn't necessarily directly help anyone in specific, especially small sites.

(This general improvement in CA practices has enabled what I feel is one real TLS security improvement for (small) websites, but that's another entry.)

PS: I don't think this is a new observation about Certificate Transparency, but I feel like writing it down anyway.

Written on 22 October 2022.
« The Prometheus timestamp() function can be used on expressions, sort of
Why I feel DNS CAA records are a real TLS security improvement in practice »

Page tools: View Source.
Search:
Login: Password:

Last modified: Sat Oct 22 21:35:20 2022
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.