9 ms·

I'm giving up on HPKP

127 points by el_duderino 9y ago

rrdharan 9y ago
I'm very curious to hear what the community thinks of the dangers outlined here. I've been hesitant about setting up HPKP before for small unimportant personal sites before since I have poor operational hygiene for them (I keep my machines patched so I don't get pwned but I have lost SSL keys before due to laziness or forgetfulness).
- vbezhenar 9y ago
  It's hard for me to justify a technology which could do very serious damage to a domain. I did the same, I set up HPKP for my domain and then I've lost my keys (I forget to pay for hosting and server was deactivated). It's not a big deal for me, I'm not really using this domain, but even with this throwaway site I've had problems, when I uploaded some file and sent link to my friend, but he wasn't able to download it, because he was there before. Blackmailing domain owners with HPKP is a real threat as well. It'll happen, sooner or later, servers are getting owned all the time. Defacing front page is visible. Setting additional header is not.
  - Ajedi32 9y ago
    > I've lost my keys (I forget to pay for hosting and server was deactivated) Both of them? You mean you were storing your backup key on the same server the main key was on? Doesn't that kinda defeat the purpose of having a backup key in the first place?
    - skywhopper 9y ago
      Mistakes happen. New certs and keys can be easily acquired if you lose the key. But HPKP prevents you from fixing this simple mistake in order to guard against a problem that's extremely unlikely.
- ivanr 9y ago
  HPKP, in its current shape, is difficult to justify even to larger companies. Presumably, those companies who do consider it determined that there is a non-significant risk that they would be attacked via fraudulent (but of course valid) certificates. Given that unimportant sites don't face that risk, there's no reason to use HPKP for them.
- skywhopper 9y ago
  Essentially there's little or no likely gain in security or trust to be had by using HPKP, but you add a lot of risk to your operation if you do use it. It's like putting a nuclear bomb on a hair trigger in order to protect against the risk that mutant zombie rats will set up a lemonade stand in front of your McDonald's franchise: an overkill solution to an extremely unlikely threat.
Gasparila 9y ago
This article (and others I have read disliking HPKP) generally take an all or nothing approach. That is to say, they see HPKP as either "pin the key of my certificate" or "don't use HPKP at all" In reality, you can have a valid HPKP setup as long as any keys in your certificate chain match the key in the HPKP header. This means that you can pin the intermediate certificate (or even the root CA if you want) key. By doing so, you are no longer vulnerable to losing your SSL keys, but now other CAs cannot issue certificates for your site
- ivanr 9y ago
  No, you're wrong. There are no guarantees that you'd be able to get a fresh certificate from the same intermediate certificate. CAs rotate the intermediates all the time, for various reasons. Of course, CAs can choose to make such guarantees ("the public key behind this intermediate will continue to be available for N years"), which would make the pinning much less dangerous.
  - sdeziel 9y ago
    That's why it's nice of Let's Encrypt to publish their current and backup intermediate CAs (X3 and X4) https://letsencrypt.org/certificates/ https://letsencrypt.org/certificates/. That's what I pin for my sites.
    - pfg 9y ago
      It's worth noting that Let's Encrypt makes no guarantees regarding the ability to sign under either key[1]. Both keys could be rotated without prior notice (though that would admittedly be unlikely unless there's an emergency). [1]: https://community.letsencrypt.org/t/official-hpkp-support-from-lets-encrypt/23753/17?u=pfg https://community.letsencrypt.org/t/official-hpkp-support-fr...
      - schoen 9y ago
        For example, some kinds of HSM bugs might conceivably lead to issuing a new intermediate after an HSM software update (like if an HSM vendor said that it had concluded that its CSPRNG was seeded inadequately with fewer effective bits of entropy than the specifications required, or something). In support of being cautious about predicting what intermediate will be used for issuance at a given time, there was also once a Let's Encrypt Authority X2 (also browser-trusted by virtue of being signed by IdenTrust's root), but issuance skipped directly from the X1 to the X3 intermediate in March 2016. https://letsencrypt.org/certs/lets-encrypt-x2-cross-signed.pem.txt https://letsencrypt.org/certs/lets-encrypt-x2-cross-signed.p... https://crt.sh/?Identity=%25&iCAID=7395 https://crt.sh/?Identity=%25&iCAID=7395 https://crt.sh/?Identity=%25&iCAID=16418 https://crt.sh/?Identity=%25&iCAID=16418
hyperfekt 9y ago
Am I mistaken to think that the HKPKP attacks could be mitigated to a certain degree by implementing delayed pinning - meaning a pin must be announced for a certain amount of time before it goes into effect, allowing the owner to notice and counteract a malicious pinning.
- georgyo 9y ago
  HKPKP is a header in http request, there is no where to announce it early.
  - icebraining 9y ago
    The idea is that browsers would see that header, but only enforce the pin if the header was kept for a certain period.
- ivanr 9y ago
  Yes, you're right. IIRC, that approach was considered and rejected in the design phase. Some other pinning proposals (e.g. http://tack.io http://tack.io) rely on delayed activation to reduce the damage potential.
SadWebDeveloper 9y ago
Let's Encrypt set HPKP on suicide watch. Let's Encrypt devs decided to put those short-lived certs (instead of the long-term certs everyone was using) making it almost irrelevant to use that "security header", almost every webdev knows the issues present on the current cache-invalidation problems on every major browser.
- wbkang 9y ago
  I know let's encrypt certbot rotates certs but does it also rotate private keys every 3 months?
  - SadWebDeveloper 9y ago
    HPKP uses public keys and AFAIK it rotates them by default every 90 days (unless you explicitly said no). HPKP and Let's encrypt has been a notable problem on the Let's encrypt community, if you see my reply to an earlier comment you can read the links on the problem it brings, it has even been proposed to use long-term certs (https://github.com/certbot/certbot/issues/2083 https://github.com/certbot/certbot/issues/2083) but the devs didn't like it therefore since it's not recommended and encouraged by one of the major free ssl certificate authorities it just means that it will less people will implement it and browser will eventually cut the support.
    - throw2016 9y ago
      Why this high handed approach by the letsencrypt team? This completely arbitrary 90 day limit makes little sense when the world has been using 1 and 3 year certs without issue. This seems to be very little justification for it apart from questionable security assumptions that will not stand up to scrutiny. Are they suggesting sites not using letsencrypt are insecure? Why make assumptions in the first place about day to day server security when you are in the business of issuing certificates? This just reflects a patronizing attitude that places constraints on others because of individual preferences. If they want to advocate 90 day renewals a more reasonable approach is a separate team to provide tools and advocate 90 days renewals.
arkadiyt 9y ago
Lots of good HPKP discussion on infosec twitter as a result of this article. I agree that HPKP in enforce mode is too dangerous to be valuable, but running HPKP in report-only mode can be an effective canary against (poorly executed) MITM attacks or other accidental server/router/ISP/etc misconfigurations.
kardos 9y ago
Re: HPKP suicide, why not pin a handful of 'recovery' keys that you can use when things go sour? Stored off-server or offline so in the hack scenario you don't lose them.
- astrodust 9y ago
  In a "hack scenario" theoretically everything can be compromised.
  - Ajedi32 9y ago
    Sure, in theory. Realistically though, I think any scenario that involves compromising both the production server _and_ a USB drive locked in a safe is pretty unlikely.
    - pfg 9y ago
      The interesting bit about RansomPKP is that it works independent of whether your HPKP pinning strategy is sound. In fact, it works even if you don't use HPKP at all. All the attacker needs is the ability to modify your HTTP headers and to either have access to your existing private key, or the ability to change the private key to one under their control. From that point on, it's all about how long it'll take you to notice the modified header. If it's live long enough for a sufficiently large percentage of your visitors to hit the site, the damage is done. One thing to take away from this is that RansomPKP is not so much an argument you can use when deciding whether you should deploy HPKP for a particular site, but rather something that's relevant for deciding whether browsers should continue to support HPKP in its current form at all. I could see how a couple of large RansomPKP cases could very well cause a change on that front.
      - buu700 9y ago
        Actually, more than just being independent of your pinning strategy, one of the partial mitigations that Bryant (@eganist) and I recommended when introducing RansomPKP was to enable HPKP, since it would both block existing users of the target site from pinning the new malicious headers and cause alarm bells to be set off early. Like you said, RansomPKP is more impactful to the ecosystem-wide decision of whether HPKP should exist than to whether an individual should use it (given the precondition that it exists). That said, malicious pinning was explicitly discussed and noted as a concern during the standardization process, so RansomPKP doesn't add much to that ecosystem-wide decision; it's just a fun application of HPKP Suicide that takes the core malicious pinning idea to a logical conclusion, and isn't even necessarily the worst way to abuse a compromised web server. There are also much more positive applications of HPKP Suicide, e.g. my startup Cyph's in-browser code signing layer. Anyway, I wouldn't use any of this to argue against the very existence of HPKP, but I agree with Scott removing it from a tool that at least partially targets non-experts.
perpetualcrayon 9y ago
Does anyone here know how (or if) each of the major browsers caps max age? It appears the specification provides a hint that it's up to UA whether to cap max age. If the browsers aren't capping max age, could this affect future owners of a domain had the HPKP max age been set to several years after their ownership of the domain expired?
- hdhzy 9y ago
  They do cap: 10 weeks in Chrome, 60 days in Firefox [0] but you can still poison future owner's domain. [0]: https://mobile.twitter.com/spazef0rze/status/900698403629391877 https://mobile.twitter.com/spazef0rze/status/900698403629391...
KirinDave 9y ago
Okay, but I still think mobile app apis served over SSL that don't pin to a specific signer are making their lives way harder.
- skywhopper 9y ago
  This is true. This is an actual case where pinning is a good idea, but this sort of pinning can and should happen in the application code or config, by restricting which CAs are trusted for a particular transaction. There's no need for a generic HTTP header for this situation. Set your TLS negotiation requirements in your app.
hdhzy 9y ago
Scott, so take HPKP out of your securityheaders.io site. Encouraging people to deploy this extremely sharp tool can bring only bad results.
- GlitchMr 9y ago
  He did, on test.securityheaders.io. The change probably will move to actual site (non-test version of it) soonish.
  - hdhzy 9y ago
    Excellent! That also shows damage that can be done by people blindly perusing A+/100% on security tests. The same goes to ssllabs that needs 4096 bit RSA keys (or equivalent) to get 100%. Just... a bad idea.
mozumder 9y ago
How is HPKP supposed to work when you change certificates? The new certificates don't have HPKP and the site still relies on old HPKP. Letsencrypt certificates only lasts 90 days. It's a real pain-in-the-ass to figure out a process that allows HPKP with certificates that expire every 90 days.
- pfg 9y ago
  HPKP is based on the public key, not the certificate. You can continue to use a certificate with the same public key across renewals. You could even switch to a different CA if you pin to the key of your server (end-entity) certificate. That said, most experts recommend pinning to a number of CA roots or intermediates instead of pinning solely to keys under your control. (Backup pins to keys under your control are still recommended.)
- ivanr 9y ago
  If you continue to use the same public key, your existing pin will work with your new certificate. So there's nothing to do. IIRC, many (all?) LE clients generate new keys by default, so this is something you need to plan for in advance. If you want to change your public key, you have to obtain your certificate in advance, then introduce its pin into your HPKP configuration at least N days before the certificate switch. In this case, N is your maximum HPKP policy duration. With this process you ensure that, when you do switch the certificates, all your users will have the correct pin for it. Whatever HPKP policy you had N+1 days prior, it will have expired by then. You probably want some additional safety margin there too.
skywhopper 9y ago
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.

127 points by el_duderino 9y ago

I'm very curious to hear what the community thinks of the dangers outlined here. I've been hesitant about setting up HPKP before for small unimportant personal sites before since I have poor operational hygiene for them (I keep my machines patched so I don't get pwned but I have lost SSL keys before due to laziness or forgetfulness).

vbezhenar 9y ago
It's hard for me to justify a technology which could do very serious damage to a domain. I did the same, I set up HPKP for my domain and then I've lost my keys (I forget to pay for hosting and server was deactivated). It's not a big deal for me, I'm not really using this domain, but even with this throwaway site I've had problems, when I uploaded some file and sent link to my friend, but he wasn't able to download it, because he was there before. Blackmailing domain owners with HPKP is a real threat as well. It'll happen, sooner or later, servers are getting owned all the time. Defacing front page is visible. Setting additional header is not.
- Ajedi32 9y ago
  > I've lost my keys (I forget to pay for hosting and server was deactivated) Both of them? You mean you were storing your backup key on the same server the main key was on? Doesn't that kinda defeat the purpose of having a backup key in the first place?
  - skywhopper 9y ago
    Mistakes happen. New certs and keys can be easily acquired if you lose the key. But HPKP prevents you from fixing this simple mistake in order to guard against a problem that's extremely unlikely.
ivanr 9y ago
HPKP, in its current shape, is difficult to justify even to larger companies. Presumably, those companies who do consider it determined that there is a non-significant risk that they would be attacked via fraudulent (but of course valid) certificates. Given that unimportant sites don't face that risk, there's no reason to use HPKP for them.
skywhopper 9y ago
Essentially there's little or no likely gain in security or trust to be had by using HPKP, but you add a lot of risk to your operation if you do use it. It's like putting a nuclear bomb on a hair trigger in order to protect against the risk that mutant zombie rats will set up a lemonade stand in front of your McDonald's franchise: an overkill solution to an extremely unlikely threat.

Gasparila 9y ago

This article (and others I have read disliking HPKP) generally take an all or nothing approach. That is to say, they see HPKP as either "pin the key of my certificate" or "don't use HPKP at all" In reality, you can have a valid HPKP setup as long as any keys in your certificate chain match the key in the HPKP header. This means that you can pin the intermediate certificate (or even the root CA if you want) key. By doing so, you are no longer vulnerable to losing your SSL keys, but now other CAs cannot issue certificates for your site

ivanr 9y ago
No, you're wrong. There are no guarantees that you'd be able to get a fresh certificate from the same intermediate certificate. CAs rotate the intermediates all the time, for various reasons. Of course, CAs can choose to make such guarantees ("the public key behind this intermediate will continue to be available for N years"), which would make the pinning much less dangerous.
- sdeziel 9y ago
  That's why it's nice of Let's Encrypt to publish their current and backup intermediate CAs (X3 and X4) https://letsencrypt.org/certificates/ https://letsencrypt.org/certificates/. That's what I pin for my sites.
  - pfg 9y ago
    It's worth noting that Let's Encrypt makes no guarantees regarding the ability to sign under either key[1]. Both keys could be rotated without prior notice (though that would admittedly be unlikely unless there's an emergency). [1]: https://community.letsencrypt.org/t/official-hpkp-support-from-lets-encrypt/23753/17?u=pfg https://community.letsencrypt.org/t/official-hpkp-support-fr...
    - schoen 9y ago
      For example, some kinds of HSM bugs might conceivably lead to issuing a new intermediate after an HSM software update (like if an HSM vendor said that it had concluded that its CSPRNG was seeded inadequately with fewer effective bits of entropy than the specifications required, or something). In support of being cautious about predicting what intermediate will be used for issuance at a given time, there was also once a Let's Encrypt Authority X2 (also browser-trusted by virtue of being signed by IdenTrust's root), but issuance skipped directly from the X1 to the X3 intermediate in March 2016. https://letsencrypt.org/certs/lets-encrypt-x2-cross-signed.pem.txt https://letsencrypt.org/certs/lets-encrypt-x2-cross-signed.p... https://crt.sh/?Identity=%25&iCAID=7395 https://crt.sh/?Identity=%25&iCAID=7395 https://crt.sh/?Identity=%25&iCAID=16418 https://crt.sh/?Identity=%25&iCAID=16418

hyperfekt 9y ago

Am I mistaken to think that the HKPKP attacks could be mitigated to a certain degree by implementing delayed pinning - meaning a pin must be announced for a certain amount of time before it goes into effect, allowing the owner to notice and counteract a malicious pinning.

georgyo 9y ago
HKPKP is a header in http request, there is no where to announce it early.
- icebraining 9y ago
  The idea is that browsers would see that header, but only enforce the pin if the header was kept for a certain period.
ivanr 9y ago
Yes, you're right. IIRC, that approach was considered and rejected in the design phase. Some other pinning proposals (e.g. http://tack.io http://tack.io) rely on delayed activation to reduce the damage potential.

SadWebDeveloper 9y ago

Let's Encrypt set HPKP on suicide watch. Let's Encrypt devs decided to put those short-lived certs (instead of the long-term certs everyone was using) making it almost irrelevant to use that "security header", almost every webdev knows the issues present on the current cache-invalidation problems on every major browser.

wbkang 9y ago
I know let's encrypt certbot rotates certs but does it also rotate private keys every 3 months?
- SadWebDeveloper 9y ago
  HPKP uses public keys and AFAIK it rotates them by default every 90 days (unless you explicitly said no). HPKP and Let's encrypt has been a notable problem on the Let's encrypt community, if you see my reply to an earlier comment you can read the links on the problem it brings, it has even been proposed to use long-term certs (https://github.com/certbot/certbot/issues/2083 https://github.com/certbot/certbot/issues/2083) but the devs didn't like it therefore since it's not recommended and encouraged by one of the major free ssl certificate authorities it just means that it will less people will implement it and browser will eventually cut the support.
  - throw2016 9y ago
    Why this high handed approach by the letsencrypt team? This completely arbitrary 90 day limit makes little sense when the world has been using 1 and 3 year certs without issue. This seems to be very little justification for it apart from questionable security assumptions that will not stand up to scrutiny. Are they suggesting sites not using letsencrypt are insecure? Why make assumptions in the first place about day to day server security when you are in the business of issuing certificates? This just reflects a patronizing attitude that places constraints on others because of individual preferences. If they want to advocate 90 day renewals a more reasonable approach is a separate team to provide tools and advocate 90 days renewals.

arkadiyt 9y ago

Lots of good HPKP discussion on infosec twitter as a result of this article. I agree that HPKP in enforce mode is too dangerous to be valuable, but running HPKP in report-only mode can be an effective canary against (poorly executed) MITM attacks or other accidental server/router/ISP/etc misconfigurations.

kardos 9y ago

Re: HPKP suicide, why not pin a handful of 'recovery' keys that you can use when things go sour? Stored off-server or offline so in the hack scenario you don't lose them.

astrodust 9y ago
In a "hack scenario" theoretically everything can be compromised.
- Ajedi32 9y ago
  Sure, in theory. Realistically though, I think any scenario that involves compromising both the production server _and_ a USB drive locked in a safe is pretty unlikely.
  - pfg 9y ago
    The interesting bit about RansomPKP is that it works independent of whether your HPKP pinning strategy is sound. In fact, it works even if you don't use HPKP at all. All the attacker needs is the ability to modify your HTTP headers and to either have access to your existing private key, or the ability to change the private key to one under their control. From that point on, it's all about how long it'll take you to notice the modified header. If it's live long enough for a sufficiently large percentage of your visitors to hit the site, the damage is done. One thing to take away from this is that RansomPKP is not so much an argument you can use when deciding whether you should deploy HPKP for a particular site, but rather something that's relevant for deciding whether browsers should continue to support HPKP in its current form at all. I could see how a couple of large RansomPKP cases could very well cause a change on that front.
    - buu700 9y ago
      Actually, more than just being independent of your pinning strategy, one of the partial mitigations that Bryant (@eganist) and I recommended when introducing RansomPKP was to enable HPKP, since it would both block existing users of the target site from pinning the new malicious headers and cause alarm bells to be set off early. Like you said, RansomPKP is more impactful to the ecosystem-wide decision of whether HPKP should exist than to whether an individual should use it (given the precondition that it exists). That said, malicious pinning was explicitly discussed and noted as a concern during the standardization process, so RansomPKP doesn't add much to that ecosystem-wide decision; it's just a fun application of HPKP Suicide that takes the core malicious pinning idea to a logical conclusion, and isn't even necessarily the worst way to abuse a compromised web server. There are also much more positive applications of HPKP Suicide, e.g. my startup Cyph's in-browser code signing layer. Anyway, I wouldn't use any of this to argue against the very existence of HPKP, but I agree with Scott removing it from a tool that at least partially targets non-experts.

perpetualcrayon 9y ago

Does anyone here know how (or if) each of the major browsers caps max age? It appears the specification provides a hint that it's up to UA whether to cap max age. If the browsers aren't capping max age, could this affect future owners of a domain had the HPKP max age been set to several years after their ownership of the domain expired?

hdhzy 9y ago
They do cap: 10 weeks in Chrome, 60 days in Firefox [0] but you can still poison future owner's domain. [0]: https://mobile.twitter.com/spazef0rze/status/900698403629391877 https://mobile.twitter.com/spazef0rze/status/900698403629391...

KirinDave 9y ago

Okay, but I still think mobile app apis served over SSL that don't pin to a specific signer are making their lives way harder.

skywhopper 9y ago
This is true. This is an actual case where pinning is a good idea, but this sort of pinning can and should happen in the application code or config, by restricting which CAs are trusted for a particular transaction. There's no need for a generic HTTP header for this situation. Set your TLS negotiation requirements in your app.

hdhzy 9y ago

Scott, so take HPKP out of your securityheaders.io site. Encouraging people to deploy this extremely sharp tool can bring only bad results.

GlitchMr 9y ago
He did, on test.securityheaders.io. The change probably will move to actual site (non-test version of it) soonish.
- hdhzy 9y ago
  Excellent! That also shows damage that can be done by people blindly perusing A+/100% on security tests. The same goes to ssllabs that needs 4096 bit RSA keys (or equivalent) to get 100%. Just... a bad idea.

mozumder 9y ago

How is HPKP supposed to work when you change certificates? The new certificates don't have HPKP and the site still relies on old HPKP. Letsencrypt certificates only lasts 90 days. It's a real pain-in-the-ass to figure out a process that allows HPKP with certificates that expire every 90 days.

pfg 9y ago
HPKP is based on the public key, not the certificate. You can continue to use a certificate with the same public key across renewals. You could even switch to a different CA if you pin to the key of your server (end-entity) certificate. That said, most experts recommend pinning to a number of CA roots or intermediates instead of pinning solely to keys under your control. (Backup pins to keys under your control are still recommended.)
ivanr 9y ago
If you continue to use the same public key, your existing pin will work with your new certificate. So there's nothing to do. IIRC, many (all?) LE clients generate new keys by default, so this is something you need to plan for in advance. If you want to change your public key, you have to obtain your certificate in advance, then introduce its pin into your HPKP configuration at least N days before the certificate switch. In this case, N is your maximum HPKP policy duration. With this process you ensure that, when you do switch the certificates, all your users will have the correct pin for it. Whatever HPKP policy you had N+1 days prior, it will have expired by then. You probably want some additional safety margin there too.

skywhopper 9y ago

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.