Comment by buu700 | Hacker News Reader

Comment by buu700 | Hacker News Reader

Parent Full thread

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), 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?

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

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-t...

2: https://scotthelme.co.uk/im-giving-up-on-hpkp

3: https://securityheaders.io

I will be VERY upfront that I DO blame Scott Helme for this. I mentioned this in 2/2016 as well[0]

It's fair. There was a lot of buzz about Ransom HPKP. The whole thing was doomed from the start, and I was pretty upset every time I saw anyone publicly push for it.

0: https://twitter.com/ejcx_/status/698227927390023681

I worked with Scott on the HPKP components of that initial blog post (I'm sure he can confirm) and I won't blame him at all for what took place in hindsight. Google actually denied a bounty on disclosures surrounding RansomPKP, so there was nothing to suggest this was the path they would eventually follow.

Again, I think this decision has nothing to do with Ransom HPKP and everything to do with how it's not a usable standard, and people who try to use it correctly fail.

Huh, well that's an interesting point. I don't know exactly how popular Security Headers is, but given that it's at least partially targeted at novices, I can see how this backlash might have been avoided if HPKP had been omitted there from the start.

Well in fairness, our talk probably wouldn't have been accepted by either Black Hat or DEF CON if we omitted RansomPKP. Or any of the HPKP suicide stuff.

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.

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

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.

Here's a potentially easier to read (doesn't require JavaScript) document explaining 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

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

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.

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):"

See my reply above to @ejcx.

Reply on news.ycombinator.com