2 ms·

The decision to use HPKP is about balancing risks. You're reducing the risk that a compromised CA can issue a fake certificate for your site (the use of which a

The decision to use HPKP is about balancing risks. You're reducing the risk that a compromised CA can issue a fake certificate for your site (the use of which also requires either DNS compromise or some targeted MITM hijacking) in exchange for increasing the risk that operational failure or the need to rotate certificates more quickly than anticipated will block all users from your site for a potentially long period of time. The questions to ask are: how bad is the failure case, how likely is it, and how hard is it to recover from? All three answers, IMO, weigh strongly in favor of _not_ using HPKP. An invalidly issued certificate is hard to make use of, except in targeted situations (malicious wifi for DNS spoofing, or a compromise of trusted root certs on the target machine), or for limited amounts of time (actual DNS takeover). So the number of users affected would be small in either case. And if there's a root CA out there granting invalid certificates, there's enough interest in keeping the trusted roots clean that it would get patched up pretty quickly anyway. So, the impact is low, the probability is low, and the recovery is relatively quick. But HPKP is rife with opportunities to screw yourself over unless you're extremely careful. And a mistake can potentially affect all your users for whatever period you configured the pinning to be for (which might be months or longer if you don't think it through or just make a mistake). Recovering from that is difficult or impossible. So given those tradeoffs, the choice seems obvious to me. It's far easier for attackers to just use a different domain name and count on people not realizing or not even knowing which site they are visiting. That requires no CA compromise, no trusted-root hacking, no DNS MITM, no wifi trolling. HPKP is a problematic solution to a problem no one actually has.

schoen 9y ago
> So the number of users affected would be small in either case. And if there's a root CA out there granting invalid certificates, there's enough interest in keeping the trusted roots clean that it would get patched up pretty quickly anyway. However, HPKP is one of the mechanisms today that can best detect this activity happening. (In the future, CT with mandatory log inclusion proofs should be better.) People don't just learn about misissuance events by magic, but by having technologies that provide other channels for checking what certificates exist in the wild or what certificates UAs should expect. Also, some misissuance can be unintentional on the CA's part, so pinning can conceivably also help clean up the CA's practices. You might be right that these factors weight against HPKP most of the time, but for the core misissuance-detection one, the situation is a bit more complicated because of the way that HPKP itself helps with catching these situations.
- syrrim 9y ago
  There is a header one can set, as an alternative to HPKP, that will merely notify you in the event of a misissuance, rather than block off your domain. Perhaps that would be preferable?
  - schoen 9y ago
    Yes, the notification mode would probably often be sufficient in many cases (and I think might be what caught the DigiNotar compromise?). I forgot what happens if an attacker tries to block the notification from going through, though.
3pt14159 9y ago
I take the middle way: Add root Comodo and one other CA as valid fingerprints. Now an attacker would not only need to execute the MITM attack (which is actually pretty easy and pretty common, which I think you're downplaying, but whatever) but they also need to have hacked one of two CA providers that reside in the USA. If my threat vector is passive collection by state actors or state supported actors like some cyber criminals, then I've mitigated most of if. Only the USA could still easily get my site. But I have to trust them anyway because they create my computer (including CPU, network adapter, and OS), Github account, email, router, and phone. Short of using a 0day or something similar against my server, which I admit is possible, the attacker cannot easily bulk collect / fabricate / tamper requests to and from my server. I agree it isn't perfect, but it's good enough.
apple4ever 9y ago
Exactly the conclusion I came to as well.

schoen 9y ago

> So the number of users affected would be small in either case. And if there's a root CA out there granting invalid certificates, there's enough interest in keeping the trusted roots clean that it would get patched up pretty quickly anyway. However, HPKP is one of the mechanisms today that can best detect this activity happening. (In the future, CT with mandatory log inclusion proofs should be better.) People don't just learn about misissuance events by magic, but by having technologies that provide other channels for checking what certificates exist in the wild or what certificates UAs should expect. Also, some misissuance can be unintentional on the CA's part, so pinning can conceivably also help clean up the CA's practices. You might be right that these factors weight against HPKP most of the time, but for the core misissuance-detection one, the situation is a bit more complicated because of the way that HPKP itself helps with catching these situations.

syrrim 9y ago
There is a header one can set, as an alternative to HPKP, that will merely notify you in the event of a misissuance, rather than block off your domain. Perhaps that would be preferable?
- schoen 9y ago
  Yes, the notification mode would probably often be sufficient in many cases (and I think might be what caught the DigiNotar compromise?). I forgot what happens if an attacker tries to block the notification from going through, though.

3pt14159 9y ago

I take the middle way: Add root Comodo and one other CA as valid fingerprints. Now an attacker would not only need to execute the MITM attack (which is actually pretty easy and pretty common, which I think you're downplaying, but whatever) but they also need to have hacked one of two CA providers that reside in the USA. If my threat vector is passive collection by state actors or state supported actors like some cyber criminals, then I've mitigated most of if. Only the USA could still easily get my site. But I have to trust them anyway because they create my computer (including CPU, network adapter, and OS), Github account, email, router, and phone. Short of using a 0day or something similar against my server, which I admit is possible, the attacker cannot easily bulk collect / fabricate / tamper requests to and from my server. I agree it isn't perfect, but it's good enough.

apple4ever 9y ago

Exactly the conclusion I came to as well.