3 ms·

Could you elaborate more? I’ve seen advice that it’s not recommended (and not been recommended for some years), but I’ve also seen questions in recent times by

by AnonHP 5y ago

Could you elaborate more? I’ve seen advice that it’s not recommended (and not been recommended for some years), but I’ve also seen questions in recent times by app developers who are bent on using it to “increase the security” (as it relates to where the apps want to connect to securely without any interception/modification).

freeone3000 5y ago
HPKP locks you into one public key forever, so you can't ever rotate private keys for your website. (You can rotate the cert, but this isn't the same.) Heartbleed was one time where your keys would be leaked and you'd have to rotate, but even normal business processes prefer key rotation (and heaven forfend you ever lose it!). Too much burden for too little gain.
- rossy 5y ago
  No, HPKP didn't lock you into one public key forever. You could rotate keys. The HPKP header had an expiry date and let you specify multiple keys, so you could add a new key to the list and switch over when the previous key expired.
- smnrchrds 5y ago
  Plus, I think it can make a domain unusable forever. You can end up buying a domain you cannot use because the previous owner had used HPKP.
- toast0 5y ago
  It makes sense to use HPKP to pin to a CA (maybe a CA's intermediate, I can't remember what they let you do) or better, multiple. Depending on your expiration, and what terrible thing happens in the PKI universe, you should probably be able to resolve an issue if you've got multiple independent CAs pinned.
buu700 5y ago
Sure, I'll just defer to an older comment on this: https://news.ycombinator.com/item?id=17779395 https://news.ycombinator.com/item?id=17779395 --- 8 points by buu700 on Aug 17, 2018 | parent | favorite | on: OpenPGPjs has passed an independent security audit We (Cyph) have been pretty disappointed in the Chrome team's decision to kill HPKP. Paraphrasing, but IIRC the reasoning pretty much boiled down to "it's a pain to maintain and Expect-CT is kind of similar anyway" — which I think is a really weak justification for harming end user security and breaking established APIs that people depend on in production. Fingers crossed that Firefox keeps it alive! [Narrator: They didn't.] That said, it doesn't entirely break WebSign in Chrome, just weakens a bit further below strict TOFU. https://www.cyph.com/websign https://www.cyph.com/websign goes into detail, but WebSign has some client-side logic to validate its own hash against a signed whitelist. The major downsides to relying on this are: 1. It depends on a caching layer, not a security feature. This means that any guarantees are potentially out the window if a browser vendor decides to do something crazy for performance reasons or whatever. 2. It opens up an attack vector where it can be forcibly unpinned by filling up the user's disk and making the browser evict the cached WebSign instance. All in all I think it's still basically fine, but shipping an optional browser extension for hardening WebSign is now a higher priority because of this.
- bawolff 5y ago
  Hmm, https://www.cyph.com/websign-architecture https://www.cyph.com/websign-architecture the hkpk suicide bit is a beautiful hack, but is so far removed from the motivating purpose of hpkp, that i dont think you can really blame web browsers for not caring. Although i guess im kind of surprised that worked. I'd assume that service workers could fall out of cache before hkpk at random, and then your app would just be bricked (?) Seems like a bad failure case that could just happen without anything makicious going on, but maybe i just dont understand how service workers work well enough.
  - buu700 5y ago
    Ah yeah, 100% agreed. I think it was a cool concept, but if we're being fair we were practically exploiting a vulnerability in HPKP to produce unintended behavior. (On that note, one of the HPKP Suicide demos we presented at Black Hat and DEF CON was actually a ransomware concept.) I'd assume that service workers could fall out of cache before hkpk at random, and then your app would just be bricked Well... that did actually happen on occasion, although IIRC it was considered to be an edge case browser bug in the ServiceWorker and/or Persistent Storage implementations rather than expected behavior, since the locally installed worker shouldn't have been wiped before its replacement had been successfully fetched. We had to set up a support page with instructions to unpin the keys through about:config / chrome://net-internals, which wasn't really ideal. (Both browsers did end up actually fixing this, not that it ultimately did us much good.)

by AnonHP 5y ago

freeone3000 5y ago

HPKP locks you into one public key forever, so you can't ever rotate private keys for your website. (You can rotate the cert, but this isn't the same.) Heartbleed was one time where your keys would be leaked and you'd have to rotate, but even normal business processes prefer key rotation (and heaven forfend you ever lose it!). Too much burden for too little gain.

rossy 5y ago
No, HPKP didn't lock you into one public key forever. You could rotate keys. The HPKP header had an expiry date and let you specify multiple keys, so you could add a new key to the list and switch over when the previous key expired.
smnrchrds 5y ago
Plus, I think it can make a domain unusable forever. You can end up buying a domain you cannot use because the previous owner had used HPKP.
toast0 5y ago
It makes sense to use HPKP to pin to a CA (maybe a CA's intermediate, I can't remember what they let you do) or better, multiple. Depending on your expiration, and what terrible thing happens in the PKI universe, you should probably be able to resolve an issue if you've got multiple independent CAs pinned.

buu700 5y ago

Sure, I'll just defer to an older comment on this: https://news.ycombinator.com/item?id=17779395 https://news.ycombinator.com/item?id=17779395 --- 8 points by buu700 on Aug 17, 2018 | parent | favorite | on: OpenPGPjs has passed an independent security audit We (Cyph) have been pretty disappointed in the Chrome team's decision to kill HPKP. Paraphrasing, but IIRC the reasoning pretty much boiled down to "it's a pain to maintain and Expect-CT is kind of similar anyway" — which I think is a really weak justification for harming end user security and breaking established APIs that people depend on in production. Fingers crossed that Firefox keeps it alive! [Narrator: They didn't.] That said, it doesn't entirely break WebSign in Chrome, just weakens a bit further below strict TOFU. https://www.cyph.com/websign https://www.cyph.com/websign goes into detail, but WebSign has some client-side logic to validate its own hash against a signed whitelist. The major downsides to relying on this are: 1. It depends on a caching layer, not a security feature. This means that any guarantees are potentially out the window if a browser vendor decides to do something crazy for performance reasons or whatever. 2. It opens up an attack vector where it can be forcibly unpinned by filling up the user's disk and making the browser evict the cached WebSign instance. All in all I think it's still basically fine, but shipping an optional browser extension for hardening WebSign is now a higher priority because of this.

bawolff 5y ago
Hmm, https://www.cyph.com/websign-architecture https://www.cyph.com/websign-architecture the hkpk suicide bit is a beautiful hack, but is so far removed from the motivating purpose of hpkp, that i dont think you can really blame web browsers for not caring. Although i guess im kind of surprised that worked. I'd assume that service workers could fall out of cache before hkpk at random, and then your app would just be bricked (?) Seems like a bad failure case that could just happen without anything makicious going on, but maybe i just dont understand how service workers work well enough.
- buu700 5y ago
  Ah yeah, 100% agreed. I think it was a cool concept, but if we're being fair we were practically exploiting a vulnerability in HPKP to produce unintended behavior. (On that note, one of the HPKP Suicide demos we presented at Black Hat and DEF CON was actually a ransomware concept.) I'd assume that service workers could fall out of cache before hkpk at random, and then your app would just be bricked Well... that did actually happen on occasion, although IIRC it was considered to be an edge case browser bug in the ServiceWorker and/or Persistent Storage implementations rather than expected behavior, since the locally installed worker shouldn't have been wiped before its replacement had been successfully fetched. We had to set up a support page with instructions to unpin the keys through about:config / chrome://net-internals, which wasn't really ideal. (Both browsers did end up actually fixing this, not that it ultimately did us much good.)