I'm giving up on HPKP
scotthelme.co.uk
scotthelme.co.uk
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.
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.
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.
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.
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
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.
[1]: https://community.letsencrypt.org/t/official-hpkp-support-fr...
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.p...
If you pin your public key, it's easy to switch CAs if the one you currently use goes under. This does happen.[1] But you are in trouble if you lose your key somehow.
If you pin your CA's public key, it's easy to recover from losing your key but you can't switch CAs until your pin expires. You could use the required second HPKP pin to add a fallback CA though.
I will note that this decision is not actually the hard part of deploying HPKP.
[1] https://blog.mozilla.org/security/2016/10/24/distrusting-new...
Or pin current CA + current pubkey? That way you can either change certificate within the current CA or use the current certificate to move to any new CA.
There is some value in ensuring that a CA is willing to sign a certificate using those keys in case something went wrong during the key generation (i.e. a key size or curve that's not supported by the Web PKI), so it might be considered a best practice to do that regardless.
It's easier to just get a full cert ahead of time.
It worked out OK for Barclays in the end, but only because Symantec was willing to violate the Baseline Requirements to help them out. (I wonder how much that cost Barclays.)
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.
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) 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.
The vast majority of sites should probably not use HPKP. Those sites will benefit from key rotation, and defaulting to anything else would make them less secure in a Heartbleed-like event.
Client support for opting out of key rotation is a different matter. Many clients already offer this, just like certbot does with --csr, but that's very annoying to use. IIRC certbot has an open PR that adds key reuse support during renewal.
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.
> This completely arbitrary 90 day limit makes little sense when the world has been using 1 years, 3 year certs without issue.
Browsers vendors (most notably Google and Mozilla) have been pushing for shorter certificate lifetimes for years. 3-year certificates have been banned starting with March 2018 (the new limit being something like 2 years and 2 months). Google itself has settled on 90-day certificates for most of their web properties, and they continue to push for shorter lifetimes in the CA/B Forum and might very well start enforcing it through their own root policy if no consensus is reached.
> 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 lets encrypt are insecure?
[citation needed]. For a long discussion on the pros and cons, see [1].
> Why make assumptions in the first place about day to day server security when you are in the business of issuing certificates?
One thing to keep in mind is that Let's Encrypt is in the business of creating a more secure and privacy-respecting Web. Naturally, it would be silly to focus solely on those two things if you actually want anyone to use your product, but if the cost of picking the more secure option isn't too high, I wouldn't expect them to go for the perhaps slightly easier option, especially given that automation is another one of their goals and the issues are mostly with manual processes.
[1]: https://community.letsencrypt.org/t/pros-and-cons-of-90-day-...
And their required short certificates go against that philosophy. Allowing short ones is fine. Requiring it is dumb.
And that discussion had very little good pros.
I feel the short certificate discussion nicely mirrors the short password discussion- both short proponents have little good arguments on their site.
It actually goes against their stated policy of encrypting the entire Internet, because it makes it so much harder or riskier to keep the certificate up to date (yes, even with automation).
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.
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).
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.
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?
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.
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.
Huh? How? If the header changes, don't browsers automatically update their pins next time the user visits that page?
> [...]and cause alarm bells to be set off early
I don't get this either. If an attacker enabling HPKP wouldn't set off any alarm bells, why would changing an existing HPKP header do that?
As far as early alarm bells, sorry, that was a bit vague. I was referring to not just ambiguous warning signs that would be caught by careful monitoring, but the inevitable stream of reports from end users about the big scary TLS pinning error screen in the browser, should the attacker decide to immediately push out the malicious keys/headers without waiting out the old ones' expiry.
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?
[0]: https://mobile.twitter.com/spazef0rze/status/900698403629391...
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.
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.)
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.