3 ms·

>"in some forms (HPKP) it's also a ransom mechanism ..." Is this ransom as in "ransomware"? Can you explain how pinning and HPKP are a ransom mechanism? >"TOF

>"in some forms (HPKP) it's also a ransom mechanism ..." Is this ransom as in "ransomware"? Can you explain how pinning and HPKP are a ransom mechanism? >"TOFU approaches which worked great for SSH in practice turn out not to suit the way ordinary users interact with the Web." How are they different exactly?

tzahola 9y ago
The issue with HPKP is that revocation is not possible if you don’t control the key that was pinned for your users. E.g. if an admin accidentally wipes the keystore, there’s no way of revoking the pinning info from the users’ browser. Taking this one step further, if an adversary enables HPKP on your behalf with a key that you don’t control, you’ll be at his mercy to keep your site operational.
- bogomipz 9y ago
  Interesting unintended consequences. Thanks for the detailed explanations. Cheers.
steventhedev 9y ago
Ransom in the sense that if you can hijack the DNS resolution for a website and set HPKP, you can then ransom the keys back to the legitimate owner. Or just destroy them and enjoy the damage. Imagine a domain squatter who grabs a domain, and sells it off, but set HPKP with a really long expiration. It needs to be strict to provide any security benefit, but that same strictness inherently allows it to be weaponized to deny legitimate access. UX and policy in the future will become more nuanced to mitigate the potential damage.
tialaramex 9y ago
>"Can you explain how pinning and HPKP are a ransom mechanism?" HPKP exists today, but probably your site doesn't use it. Bad guys break in to your servers on Monday morning before work. They leave the site working exactly as it was before, except for two things: they replace the private key value used for the site, and they add HPKP headers requiring the corresponding public key (plus optionally others of their choosing). Nobody notices. Why would they? By Friday most of your big users have accessed the site, unknown to you or them, their web browsers are now irrevocably committed by HPKP to using one of the Bad Guy's chosen keys when talking to your site. On Friday evening, the Bad Guys remove their new private key, your site mysteriously goes down for most users. You have no idea why. You receive a telephone call from someone with a disguised voice. Transfer $1M worth of Bitcoins to the address listed on a hidden page on your web site, and access will be restored. Or don't, your choice, Bye. The dependency on this key has to be irrevocable otherwise it can't achieve its security goals, this is the whole idea of pinning. But because it's irrevocable you're screwed. Either you pay the ransom or your site is "bricked" indefinitely. >"How are they different exactly?" SSH users tend to visit a small number of systems, they achieve "First use" early, from a presumed friendly system and they usually have out-of-band contact (e.g. walk over to Dave and say "Hey! Dave, I saw this error! Did you change the keys?") when things go wrong. In contrast web users often first visit a site from some unfriendly environment (e.g. a coffee shop) and the only contact details they usually have for the site operator are on the site itself.
- tptacek 9y ago
  That, again, is a browser problem. Mobile applications do not share it, since literally every user of the application is on an update channel controlled by the vendor.

tzahola 9y ago

The issue with HPKP is that revocation is not possible if you don’t control the key that was pinned for your users. E.g. if an admin accidentally wipes the keystore, there’s no way of revoking the pinning info from the users’ browser. Taking this one step further, if an adversary enables HPKP on your behalf with a key that you don’t control, you’ll be at his mercy to keep your site operational.

bogomipz 9y ago
Interesting unintended consequences. Thanks for the detailed explanations. Cheers.

steventhedev 9y ago

Ransom in the sense that if you can hijack the DNS resolution for a website and set HPKP, you can then ransom the keys back to the legitimate owner. Or just destroy them and enjoy the damage. Imagine a domain squatter who grabs a domain, and sells it off, but set HPKP with a really long expiration. It needs to be strict to provide any security benefit, but that same strictness inherently allows it to be weaponized to deny legitimate access. UX and policy in the future will become more nuanced to mitigate the potential damage.

tialaramex 9y ago

>"Can you explain how pinning and HPKP are a ransom mechanism?" HPKP exists today, but probably your site doesn't use it. Bad guys break in to your servers on Monday morning before work. They leave the site working exactly as it was before, except for two things: they replace the private key value used for the site, and they add HPKP headers requiring the corresponding public key (plus optionally others of their choosing). Nobody notices. Why would they? By Friday most of your big users have accessed the site, unknown to you or them, their web browsers are now irrevocably committed by HPKP to using one of the Bad Guy's chosen keys when talking to your site. On Friday evening, the Bad Guys remove their new private key, your site mysteriously goes down for most users. You have no idea why. You receive a telephone call from someone with a disguised voice. Transfer $1M worth of Bitcoins to the address listed on a hidden page on your web site, and access will be restored. Or don't, your choice, Bye. The dependency on this key has to be irrevocable otherwise it can't achieve its security goals, this is the whole idea of pinning. But because it's irrevocable you're screwed. Either you pay the ransom or your site is "bricked" indefinitely. >"How are they different exactly?" SSH users tend to visit a small number of systems, they achieve "First use" early, from a presumed friendly system and they usually have out-of-band contact (e.g. walk over to Dave and say "Hey! Dave, I saw this error! Did you change the keys?") when things go wrong. In contrast web users often first visit a site from some unfriendly environment (e.g. a coffee shop) and the only contact details they usually have for the site operator are on the site itself.

tptacek 9y ago
That, again, is a browser problem. Mobile applications do not share it, since literally every user of the application is on an update channel controlled by the vendor.