Why I don't use HTTP Key Pinning and I'm not likely to any time soon
One of the additional security measures you can take for a HTTPS web site is HTTP Public Key Pinning. HPKP is designed to guard against the fundamental SSL CA problem by limiting what validly signed keys can be used for your website. This way it doesn't matter if an attacker gets one of the zillion different CAs out there to issue a certificate for your website; hopefully a lot of browsers won't accept it anyways because you've told them better. A number of people like the idea of HPKP and are sad that it is used only by a trace number of websites out there.
I have looked a bit at HPKP and I'm not going to use it any time soon (either on my personal sites or at work). Fundamentally HPKP has several problems for most people. First, it's relatively hard to even set up HPKP so that it works. To simplify, a valid HPKP configuration requires you to have either a second spare TLS certificate or a second CA that you're confident you'll get a TLS certificate from if you need another one. If you go with a spare TLS certificate, you must make sure this TLS certificate is always recoverable; if you lose both your primary and your secondary certificates, you are off the air until your HPKP pinning times out. With the second CA, you must be absolutely sure that you can get a TLS certificate from the CA if you need it, and of course you're vulnerable if an attacker can get a TLS certificate for you from that specific CA.
(Note that as far as I know, you cannot specify 'this current TLS certificate or any certificate from my current CA'; your backup key must be completely independent from your current one. Also technically you don't need your secondary TLS certificate to be issued and signed by a CA, just to be pregenerated and known. This may give you some freedom. And you can specify more than one backup pin.)
Measurements in the field indicate that a lot of people get this one wrong (here's one source). Either they serve HPKP headers with only one pin or they provide two pins that aren't fully independent.
The second problem is that HPKP is very dangerous, and the more it protects you the more dangerous it is. If you set up a valid HPKP configuration and then lose both your live pin and your backup pin, you've bricked your site for people who have your HPKP information saved. The more specific your pins are and the longer you advertise them as valid, the more you're protected but also the easier it is to lose them and the longer the damage from a loss will last.
The final problem with HPKP for most sites is that it protects against what is now a very rare event that's quite risky for the attacker. It's vanishingly unlikely that your typical HTTPS site is going to be targeted by someone who can generate a valid TLS certificate for it and is willing to (quite possibly) burn a compromised CA by attacking you. This makes the reward of deploying HPKP very small compared to the risks.
If you're a big high risk site that attackers would get a big payoff from compromising, sure, HPKP makes a lot of sense. But then if you're this sort of site, you've probably already done things like ask the Chrome team to pre-pin your TLS certificates. If you'd never even dream of bugging the Chrome team for that (partly because you're too small and partly because it's a massive risk if something goes wrong), strong HPKP doesn't really make much sense.
(It might make sense to deploy reporting-only HPKP, but then you have to find or set up a reporting endpoint and then monitor things for reports, which should normally be big alerts (assuming you got your HPKP pinning right). Even with services like this, that's a fair amount of work for a fairly low likelihood risk.)
(Note that HPKP pinning can get complicated fast, since you can pin more than your current key plus one backup. With my current low level of knowledge, I'm not going to try to say anything more than that.)
|
|