TLS Certificate Transparency logs don't always talk to you

June 7, 2022

TLS Certificate Transparency is a system where browser vendors require TLS Certificate Authorities to publish information about all of their TLS certificates in cryptographically validated logs, which are generally run by third parties (see also Wikipedia). The information in CT logs is public and various people actively monitor them, sometimes for nasty purposes such as rapidly compromising new Wordpress websites (also).

Certificate transparency is partly a de facto replacement for earlier systems that attempted to do certificate revocation at scale on the web, those being Certificate Revocation Lists (CRLs) and then OCSP. One of the problems that both CRLs and OCSP checks had (and have) is that they require Certificate Authorities to reliably operate high demand web services with essentially no downtime. Unsurprisingly, they periodically didn't, and in general we shouldn't be surprised by that, since running such web services is expensive as well as challenging.

Certificate Transparency logs are also queried over HTTP, and in completely unsurprising news CT log operators don't always keep them responding (in addition to how they sometimes go away entirely). I use some third-party software to keep a vague watch for TLS certificates for domains I care about, and I've had it report on CT logs with both complete failures (timeouts and things like HTTP '502 bad gateway' responses) and clear load limits (such as HTTP '429 Too Many Requests' responses). Some of these 'bad' responses can persist for significant amounts of time (and so may indicate that a particular CT log is unhappy with my queries in specific).

In theory, maybe CT logs are not supposed to do this. In practice, CT log operators are doing this for free and we all know what happens there. No one is going to provision huge resources so they can continue to answer CT log queries under arbitrary loads (and some people's limits will be lower than others). Right now CT logs are only a bit flaky, but as the load on them inevitably grows over time I expect more of them to become more flaky. I also expect this to be selective, with queries from some sources treated much better than others (either due to private arrangements or simply that the people making the queries are too important to block).

The corollary of this is that I don't think we should build anything important on top of CT log information. CT log information can be a nice extra, but clearly we can't easily get it reliably. For example, probably my university shouldn't try to build a security thing that needs to promptly know about all TLS certificates issued for hosts in our domain. We probably couldn't expect to always be able to casually pull that from the available CT logs, although the information is theoretically there.

Written on 07 June 2022.
« Doing a selective alert about a host's additional exporters in Prometheus
The information theory reason for assuming non-secret cryptography algorithms »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Jun 7 22:27:20 2022
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.