I think Certificate Transparency is better for the web than HTTP Key Pinning

November 2, 2017

Recently, the Chrome developers announced Intent to Deprecate and Remove: Public Key Pinning (via). The unkind way to describe HTTP Public Key Pinning is that it's a great way to blow your foot off, or in our situation have well-meaning people blow it off for us. The kind way to describe HPKP is that it's intended to be a way to lessen the damage if a Certificate Authority (mis-)issues a certificate for your domain to someone else; in the right situation you can prevent that certificate from being successfully used (if browsers are willing to play along). Doubts about HPKP have been out there for some time, so this Chrome development isn't exactly surprising; even past enthusiasts have given up. Although it's not an exact replacement, today's way of dealing with the problem of (mis-)issued certificates is to increasingly insist on Certificate Transparency; you can read one view of the shift here (via).

I only have a relative outsider's view of all of this, but I've wound up feeling that Certificate Transparency is better overall for the web and for the TLS ecology than HPKP is for reasons that go beyond just the difficulty and dangers of using HPKP. One way to put the issue is that HPKP is fundamentally private and reactive, while CT logs are public and thus potentially proactive. The drawback of HPKP is that it only triggers when a bad TLS certificate is presented to a client that has pinning active; until that time, no one knows that the certificate exists, and even after that time the client may be the only one that knows (the attacker may block the client's attempt to report the HPKP violation, for example). By contrast, CT logs are public and published more or less immediately, which lets anyone monitor them for bad TLS certificates.

This matters because in general, there are two sorts of bad TLS certificates; ones that were issued through mistakes, and ones that were issued by thoroughly compromising a CA. Mistakenly issued certificates will be logged to CT logs, and so they can be detected in advance before they start doing harm to clients that don't have pinning active (or to clients that allow people to override the pinning). Certificates from fully compromised CAs will normally be kept out of CT logs precisely to avoid advance detection, but the more that browsers insist on certificates being in CT logs (and that's coming), the less that works. Also, mistakenly issued certificates seem to be far more common so far, with outright CA compromises relatively rare.

If HPKP is active in a client and the pins are carefully chosen so they're beyond an attacker's reach, HPKP may keep that client more secure than CT logs can. However, HPKP does nothing to help clients that don't have the pinning already active, and it doesn't necessarily let website operators know that there are bad certificates out there. CT logs provide somewhat less security to a highly secure client but create far higher global visibility about bad TLS certificates. This global visibility is better overall for the web; it's going to do more to increase the risks and costs of attacks with fraudulently obtained TLS certificates, for example.

If you're facing an attacker who's willing to burn their access to a CA for an immediate and relatively moderate duration attack against visitors to your website, then CT logs are clearly worse than HPKP; CT logs won't protect you against this, whereas HPKP would protect you for people with the pins active. However CT logs will at least let you know that an attack is probably happening (and you might be able to limit the damage somehow). And most websites are not dealing with attackers who're willing to expend that sort of resources. Plus, of course, most websites would never have deployed HPKP in the first place, so for them a world with CT logs is a net win.

(CT logs can't stop attacks in advance because TLS certificate revocation remains pretty much broken. In practice, the only fix for a serious attack is for browsers to rush out new versions that explicitly distrust things, and for that update to propagate to users. This takes time, and that time window is when the attackers can operate.)

PS: In theory a world with both CT logs and HPKP is a better place than a world with just CT logs. In practice, browser people have a finite amount of effort that they can devote to TLS security. Spending some of that effort on a low-usage, low-payoff feature like HPKP means that other, probably more valuable things won't get worked on. Plus, the mere existence of a feature creates complexity and surprising interactions.

Written on 02 November 2017.
« We've now seen malware in a tar archive
Illumos mountd caches netgroup lookups (relatively briefly) »

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

Last modified: Thu Nov 2 01:28:57 2017
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.