1. The fact that HPKP can create this kind of gigantic foot-gun is a pretty good sign that it actually works. So much of security technology turns out to be cosmetic. The stuff that isn't often is hazardous.
2. Don't HPKP your blog. Don't HPKP your cat-sharing starting. Key pinning is a good thing, but it doesn't need to be universally deployed.
3. In order to hijack your site with HPKP, an attacker needs to take control of your server; they probably need RCE. In other words: if you can't safely HPKP your secure messaging system (cough), you probably aren't yet qualified to be running it: something worse happened to your users than HPKP misconfiguration.
If there's a capability we're missing right now, it's probably the ability for sites with low security requirements to opt out of HPKP. Remember, the threat model for HPKP isn't fraudsters or trolls; it's state-level adversaries.
> 2. Don't HPKP your blog. Don't HPKP your cat-sharing starting. Key pinning is a good thing, but it doesn't need to be universally deployed.
Just to be clear, this is equivalent to saying don't bother with SSL for your blog or cat-sharing site (because without pinning someone else can get a cert for your blog/cat-sharing site).
> the ability for sites with low security requirements to opt out of HPKP.
opt out?! It's off by default.
> Remember, the threat model for HPKP isn't fraudsters or trolls; it's state-level adversaries.
Again, by saying HPKP is only for high security sites (now you're saying only for those threatened by state-level adversaries) you are essentially saying SSL is useless for everything less.
> > the ability for sites with low security requirements to opt out of HPKP.
> opt out?! It's off by default.
I think tptacek meant that a site owner should be able to explicitly declare that nobody should be able to pin a key, so that nobody can hijack the site in the future.
An opt-in would make more sense, since people using HPKP are those that know the most about it. Just like an opt-out, it would have to be via a different channel than HTTP headers.
That's an odd argument to make. You're essentially saying if you can't afford the most secure safe for your jewelry, just put it in a basket in front of your door instead of getting a cheaper safe that keeps most thieves out.
By suggesting HPKP is only for sites worried about nation state adversaries means deploying SSL without HPKP which leaves the door open for adversaries to get a cert issued for your domain.
Right, I don't think you got my point. You don't always need the best option. CAs are far from perfect, but the threat model for a blog or a cat-sharing site is unlikely to include adversaries who are capable of compromising a CA (whether they're nation-state adversaries or not). SSL without HPKP is probably good enough for you in that case. Saying that the traditional CA system without HPKP is as bad as a plaintext protocol is silly.
You are underestimating 1) the number of CA's embedded in your browser, 2) how easy it is to get one of those CA's to issue a cert for someone else's domain.
I think "opt out" means opting out of being able to be pinned, not just choosing not to pin. Instead of pinning a certificate, you might pin "This domain will not be pinning a certificate before $date."
That's outdated thinking. Look around at the efforts in past ~year for getting SSL everywhere. Non-SSL sites already suffer Google PageRanking[1] (maybe you want Google visibility for your blog or cat-sharing site), other consequences are not far off.
Well, TLS (allong with access controls) for his sing-along blog would have really helped Dr. Horrible stay ahead of the authorities.
In all seriousness, though, there are plenty of blogs where which page a user visits might, for instance, out a gay teen via gateway logs, hint about a private health issue, etc.
> In other words: if you can't safely HPKP your secure messaging system (cough), you probably aren't yet qualified to be running it
And of course, if you do find a defect like this in a web based secure messaging system that relies on HPKP, it'd be great if you'd report it directly to the service and allow them to fix the defect, per responsible disclosure anyway.
Well, the real risk here is that it creates a new consequence for being hacked by a criminal, right. So I can't cop out and say "people should report instead of playing HPKP games".
On the other hand, it's an internalized risk, which is kind of a beautiful thing: so many of the risks we create through poor security are externalized to end-users --- so much so that you can run a secure messaging site, get owned up, cost thousands of people their privacy, and still keep chugging along as if nothing happened. This particular risk though just wallops the owners of the site.
Unless I'm mis-understanding it doesn't just wallop the owner of the site. It wallops all of that site's users as well. I know Google is less likely to be walloped but imagine a site similar to Google docs or gmail went down until the key expires. That's not just going to affect the site, it affects all of it's users.
Users can still get their data; the owners need to stand up another hostname. They're inconvenienced. But the attack is devastating to companies, who depend on user convenience to attract and retain users.
> Well, the real risk here is that it creates a new consequence for being hacked by a criminal, right.
No disagreement from me here, which was one reason we set out to talk about RansomPKP at BH/DC in the first place :) That said, I do think this can, and should, be reported to site owners. You're not going to see much innovation if people don't take time to futz around with technologies and see what they can do with them. HPKP has plenty of potential to hurt, but as you alluded to, it's generally just your own feet in harm's way.
> This particular risk though just wallops the owners of the site.
Is there a way to mitigate the risk of automated PKP ransom attacks without just pinning yourself before they find you? My impression after reading this is that the mere existence of HPKP (as implemented) forces you to either use it or be ready to go down for 60+ days if you get owned.
1. The fact that HPKP can create this kind of gigantic foot-gun is a pretty good sign that it actually works. So much of security technology turns out to be cosmetic. The stuff that isn't often is hazardous.
2. Don't HPKP your blog. Don't HPKP your cat-sharing starting. Key pinning is a good thing, but it doesn't need to be universally deployed.
3. In order to hijack your site with HPKP, an attacker needs to take control of your server; they probably need RCE. In other words: if you can't safely HPKP your secure messaging system (cough), you probably aren't yet qualified to be running it: something worse happened to your users than HPKP misconfiguration.
If there's a capability we're missing right now, it's probably the ability for sites with low security requirements to opt out of HPKP. Remember, the threat model for HPKP isn't fraudsters or trolls; it's state-level adversaries.