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).


Comments on this page:

By Jukka at 2017-10-31 09:21:12:

How about DNS CAA?

By Alex Xu (Hello71) at 2017-10-31 12:01:51:

CT will also be effective, even if less so, against the second sort.

https://scotthelme.co.uk/a-new-security-header-expect-ct/

By cks at 2017-10-31 12:05:57:

In terms of this entry, DNS CAA only helps defend against the first sort of mis-issuing, and at that it's merely one more roadblock that the attacker has to overcome (or subvert). If you have enough access to the CA to completely bypass their usual issuance and logging systems, then someone's DNS CAA records aren't going to stop you any more than anything else in the CA's validation system and processes.

In particular, although I didn't say this explicitly in the entry, DNS CAA won't help if the CA has been compelled by state power to issue a certificate. The state will just say 'ignore DNS CAA' in the same way that it's saying 'ignore your usual validation procedures, and oh yeah make sure that this isn't published to CT logs either'.

How much of a defense DNS CAA is in the first sort of mis-issuing depends on how well operated the CA is in general. There are and have been some very sloppily operated CAs using very bad procedures (or deliberately subverted procedures), and DNS CAA is not likely to help against them any more than anything else did. If someone is attacking a well-operated CA, then DNS CAA records may well help; if nothing else you're putting an extra obstacle in the way of the attacker and making them work harder.

(I have published DNS CAA records for my own domain because, well, why not.)

By Jukka at 2018-05-15 12:44:27:

As a testimony that you continue to raise important points, I actually went and wrote the following piece (many months ago, but still motivated by this post):

https://arxiv.org/abs/1804.07604

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, View Normal, Add Comment.
Search:
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.