There are two sorts of TLS certificate mis-issuing

October 30, 2017

The fundamental TLS problem is that there are a ton of Certificate Authorities and all of them can create certificates for your site and give them to people. When talking about this, I think it's useful to talk about two different sorts of mis-issuance of these improper, unapproved certificates.

The first sort of mis-issuance is when a certificate authority's systems (computer and otherwise) are fooled or spoofed into issuing an otherwise normal certificate that the CA should not have approved. This issuance process goes through the CA's normal procedures, or something close to them. As a result, the issued certificate is subject to all of the CA's usual logging, OCSP processes (for better or worse), and so on. Crucially, this means that such certificates will normally appear in Certificate Transparency logs if the CA publishes to CT logs at all (and CAs are increasingly doing so).

The second sort of mis-issuance is when the CA is subverted or coerced into signing certificates that don't go through its normal procedures. This is what happened with DigiNotar, for example; DigiNotar was compromised, and as a result of that compromise some unknown number of certificates were improperly signed by DigiNotar. This sort of mis-issuance is much more severe than the first sort, because it's a far deeper breach and generally means that far less is known about the resulting certificates.

My impression is that so far, the first sort of mis-issuance seems much more common than the second sort. In a way this is not surprising; identity verification is tricky (whether manual or automated) and is clearly subject to a whole lot of failure modes.

The corollary to this is that mandatory Certificate Transparency logging can likely do a lot to reduce the impact and speed up the time to detection of most mis-issued certificates. While it can't do much about the second sort of mis-issuance, it can pretty reliably work against the first sort, and those are the dominant sort (at least so far). An attacker who wants to get a mis-issued certificate that isn't published to CT logs must not merely break a CA's verification systems but also somehow compromise their backend systems enough to subvert part of the regular certificate issuance processing. This is not quite a full compromise of the CA's security, but it's a lot closer to it than merely finding a way around the CA's identity verification processes (eg).

Written on 30 October 2017.
« The Illumos NFS server's caching of filesystem access permissions
We've now seen malware in a tar archive »

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

Last modified: Mon Oct 30 23:15:59 2017
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.