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 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.
Hmm, 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.
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.)
---
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 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.