3 ms·

I can't support this at all, and ironically this is partially my fault. My and @eganist's Black Hat / DEF CON talk "Abusing Bleeding Edge Web Standards for App

by buu700 9y ago

I can't support this at all, and ironically this is partially my fault. My and @eganist's Black Hat / DEF CON talk "Abusing Bleeding Edge Web Standards for AppSec Glory" demoed an exploit concept that we called "RansomPKP", which was essentially a pattern of hostile pinning that could theoretically enable pivoting from a web server compromise to holding a site for ransom. Hostile pinning was by no means a new concept, and even has some discussion in the IETF spec itself, but we found this to be a fun novel application and used it to spur some minor security improvements to browsers' HPKP implementations. However, this talk also led to concerns being vocalized about the viability of HPKP in general (https://news.ycombinator.com/item?id=12434585 https://news.ycombinator.com/item?id=12434585), ultimately leading to this. This was not our intention at all, and I don't see hostile pinning alone as a reason to give up on HPKP. I would much rather see some discussion around improving the usability of HPKP before jumping straight to putting it on the chopping block — both from a site operator's end and a user end. For example, off the top of my head, why not make it possible for users to click past the HPKP error screen like they can with any other TLS error screen?

phyzome 9y ago
I'm curious about that followup message (is that you?) about how Cyph (seems to be some sort of encrypted messaging thing) relies on "HPKP Suicide" for... in-browser code-signing? I didn't find any resources laying out exactly how this works.
- buu700 9y ago
  The first comment on that thread is from @eganist (not me, but my colleague). This is how Cyph's HPKP-based code signing works: https://cyph.team/websigndoc https://cyph.team/websigndoc tl;dr: the same idea that we showed how to apply maliciously via RansomPKP is also applied for defensive purposes, in this case to persistently pin a client-side page with logic that validates and runs signed packages.
  - dane-pgp 9y ago
    Here's a potentially easier to read (doesn't require JavaScript) document explaining WebSign: https://www.cyph.com/websign https://www.cyph.com/websign It's a really smart idea, although it did have some odd edge cases, and required you to trust that they really were throwing away the keys as promised. There is some talk in the W3C of extending the SRI standard to let a website declare that all (or just certain) included resources have been signed by an (offline) PGP key: https://github.com/w3c/webappsec/issues/449 https://github.com/w3c/webappsec/issues/449 so we might one day reach a point where running a webapp at least has the small security guarantee that a TOFU policy gives you. If this could be combined with versioned releases of webapps, and the signature appearing in something like a Binary Transparency log, then the security guarantee could actually be quite meaningful: https://wiki.mozilla.org/Security/Binary_Transparency https://wiki.mozilla.org/Security/Binary_Transparency
    - buu700 9y ago
      Thanks Dane! I'd actually just published that copy on cyph.com to edit into the above comment, and missed the edit cutoff by a couple minutes. The rest of that is very interesting! I wasn't aware of that PGP signing discussion, but it would be very exciting if it panned out.
ejcx 9y ago
I think this has very little to do with you. Hpkp was championed by a lot of security people, who in turn got a lot of people to foot gun themselves (Scott Helme even admitted that he is oftentimes one of the first people called by people who HPKP foot-gun themselves). There were only a handful of sites that actually needed HPKP level security, and ransom-hpkp was the least of people's worries. Hpkp was more dangerous to people rolling it out on purpose than it was to mass header injection or similar :/ HPKP has been doomed from the beginning. Here is sleevi saying he regrets it in 2/2016: https://twitter.com/sleevi_/status/696171562383224832 https://twitter.com/sleevi_/status/696171562383224832
- buu700 9y ago
  I agree that RansomPKP itself isn't that big a real-world concern (which was part of my point), but it did motivate the first wide discussions that I'd seen questioning whether HPKP should exist. The linked Qualys blog post / HN thread was shortly after our talk, which (along with our conversation with Scott Helme around that time) led to Scott's post "Using security features to do bad things"[1]. RansomPKP and related follow-ups are directly highlighted by Scott's recent post "I'm giving up on HPKP"[2] in which he announced his decision to remove HPKP from the Security Headers tool[3], and Scott himself is cited in this post by Chris Palmer. Note that I'm not suggesting that Scott himself is responsible for this, or that anything he's said has been in bad faith. My point is simply that my talk was one part of the chain of events that started the ball rolling on this conversation. I'm also not saying that RansomPKP / hostile pinning is the most important reason that people have for not liking HPKP — in this case Chris lists it as only one of three motivations. Clearly, the usability issues with its implementation have been a much bigger problem, which is what I would like to see serious attempts to improve on before throwing out all the work that's been done up until now. --- Edit: re: sleevi edit: the tweet you linked doesn't say anything about regretting the concept of TLS key pinning entirely, just that it's done as a header. I'll admit it's ambiguous, but that sounds to me like he would rather have kept the feature but changed the API. I would be all for deprecating the HPKP header if it were replaced with a better / more usable interface to the feature. --- 1: https://scotthelme.co.uk/using-security-features-to-do-bad-things https://scotthelme.co.uk/using-security-features-to-do-bad-t... 2: https://scotthelme.co.uk/im-giving-up-on-hpkp https://scotthelme.co.uk/im-giving-up-on-hpkp 3: https://securityheaders.io https://securityheaders.io
bitmapbrother 9y ago
From the post it would seem the very low usage numbers had more to do with it than anything you did. "Scott Helme found in August 2016 that very few of the Alex [sic] Top 1 Million sites were using HPKP (375) or the Report-Only (RO) variant (76):"
- buu700 9y ago
  See my reply above to @ejcx.

by buu700 9y ago

phyzome 9y ago

I'm curious about that followup message (is that you?) about how Cyph (seems to be some sort of encrypted messaging thing) relies on "HPKP Suicide" for... in-browser code-signing? I didn't find any resources laying out exactly how this works.

buu700 9y ago
The first comment on that thread is from @eganist (not me, but my colleague). This is how Cyph's HPKP-based code signing works: https://cyph.team/websigndoc https://cyph.team/websigndoc tl;dr: the same idea that we showed how to apply maliciously via RansomPKP is also applied for defensive purposes, in this case to persistently pin a client-side page with logic that validates and runs signed packages.
- dane-pgp 9y ago
  Here's a potentially easier to read (doesn't require JavaScript) document explaining WebSign: https://www.cyph.com/websign https://www.cyph.com/websign It's a really smart idea, although it did have some odd edge cases, and required you to trust that they really were throwing away the keys as promised. There is some talk in the W3C of extending the SRI standard to let a website declare that all (or just certain) included resources have been signed by an (offline) PGP key: https://github.com/w3c/webappsec/issues/449 https://github.com/w3c/webappsec/issues/449 so we might one day reach a point where running a webapp at least has the small security guarantee that a TOFU policy gives you. If this could be combined with versioned releases of webapps, and the signature appearing in something like a Binary Transparency log, then the security guarantee could actually be quite meaningful: https://wiki.mozilla.org/Security/Binary_Transparency https://wiki.mozilla.org/Security/Binary_Transparency
  - buu700 9y ago
    Thanks Dane! I'd actually just published that copy on cyph.com to edit into the above comment, and missed the edit cutoff by a couple minutes. The rest of that is very interesting! I wasn't aware of that PGP signing discussion, but it would be very exciting if it panned out.

ejcx 9y ago

I think this has very little to do with you. Hpkp was championed by a lot of security people, who in turn got a lot of people to foot gun themselves (Scott Helme even admitted that he is oftentimes one of the first people called by people who HPKP foot-gun themselves). There were only a handful of sites that actually needed HPKP level security, and ransom-hpkp was the least of people's worries. Hpkp was more dangerous to people rolling it out on purpose than it was to mass header injection or similar :/ HPKP has been doomed from the beginning. Here is sleevi saying he regrets it in 2/2016: https://twitter.com/sleevi_/status/696171562383224832 https://twitter.com/sleevi_/status/696171562383224832

buu700 9y ago
I agree that RansomPKP itself isn't that big a real-world concern (which was part of my point), but it did motivate the first wide discussions that I'd seen questioning whether HPKP should exist. The linked Qualys blog post / HN thread was shortly after our talk, which (along with our conversation with Scott Helme around that time) led to Scott's post "Using security features to do bad things"[1]. RansomPKP and related follow-ups are directly highlighted by Scott's recent post "I'm giving up on HPKP"[2] in which he announced his decision to remove HPKP from the Security Headers tool[3], and Scott himself is cited in this post by Chris Palmer. Note that I'm not suggesting that Scott himself is responsible for this, or that anything he's said has been in bad faith. My point is simply that my talk was one part of the chain of events that started the ball rolling on this conversation. I'm also not saying that RansomPKP / hostile pinning is the most important reason that people have for not liking HPKP — in this case Chris lists it as only one of three motivations. Clearly, the usability issues with its implementation have been a much bigger problem, which is what I would like to see serious attempts to improve on before throwing out all the work that's been done up until now. --- Edit: re: sleevi edit: the tweet you linked doesn't say anything about regretting the concept of TLS key pinning entirely, just that it's done as a header. I'll admit it's ambiguous, but that sounds to me like he would rather have kept the feature but changed the API. I would be all for deprecating the HPKP header if it were replaced with a better / more usable interface to the feature. --- 1: https://scotthelme.co.uk/using-security-features-to-do-bad-things https://scotthelme.co.uk/using-security-features-to-do-bad-t... 2: https://scotthelme.co.uk/im-giving-up-on-hpkp https://scotthelme.co.uk/im-giving-up-on-hpkp 3: https://securityheaders.io https://securityheaders.io

bitmapbrother 9y ago

From the post it would seem the very low usage numbers had more to do with it than anything you did. "Scott Helme found in August 2016 that very few of the Alex [sic] Top 1 Million sites were using HPKP (375) or the Report-Only (RO) variant (76):"

buu700 9y ago
See my reply above to @ejcx.