Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Public Key Pinning Being Removed from Chrome

groups.google.com

Post reply on HN
Print view View original

31–40 of 111 posts

Re: Public Key Pinning Being Removed from Chrome

#31

Post by buu700 »

phyzome wrote: post #29
buu700 wrote: post #19

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…

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.

Re: Public Key Pinning Being Removed from Chrome

#32

Post by lucb1e »

PhantomGremlin wrote: post #20
saas_co_de wrote: post #15

why not provide an advanced feature that alerts you any time a cert changes, similar to what we get with SSH? at least then security conscious users could make decisions for themselves.

why not provide an advanced feature that alerts you any time a cert changes Because certificates change ... all ... the ... time. Again ... and ... again ... and ... again. Years ago I tried using a Firefox addon called Certificate Patrol. I spent half my time approving changes. Here's a Stack Exchange question on exactly that topic. It's a few years old; I don't know if things have gotten better: https://security.st…

> Because certificates change ... all ... the ... time.

Not OP but I do see potential there. I've thought about it before. Try looking at it from a solution perspective rather than from "why don't we already" and "what would the issues be": certs change, yeah, but usually because they (almost) expired. We should check when Let'sEncrypt renews by default (is that 14 days before expiry?) and what common practice is, and go from there in triggering a warning.

And if there is some uncommon reason to roll over (e.g. suspected compromise), a header could be set either in advance or one could be set that signs the new fingerprint with the old key. The new one shouldn't be pinned right away since an attacker might have misused a compromised key, and a warning symbol could be displayed similar to the mixed-content warning. If someone is suspicious and it can't be delayed, they can call their bank (or whatever it is) and they'd know about it and be able to confirm things out of band.

I'm just conceptualizing but I don't see anything that's not easily solved. I think it could be a good addition.

Re: Public Key Pinning Being Removed from Chrome

#33

Post by ejcx »

buu700 wrote: post #19

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…

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

Re: Public Key Pinning Being Removed from Chrome

#34

Post by buu700 »

ejcx wrote: post #33
buu700 wrote: post #19

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…

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 dangerou…

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

Re: Public Key Pinning Being Removed from Chrome

#35

Post by nly »

sigmar wrote: post #9

Good riddance. It had low adoption and pales in comparison to what will be achieved with Certificate Transparency. DNS redirect attacks (common/easy due to social engr) combined with malicious HPKP could result in some nasty ransoming ("many of your users can't access your site unless you pay me for the key"). I've heard many surprised it hasn't happened yet. Particularly considering the lack of recourse options for…

> DNS redirect attacks (common/easy due to social engr) combined with malicious HPKP could result in some nasty ransoming

How? Someone can hijack your resolver but they still need a valid certificate for the name before they can install the pin?

Re: Public Key Pinning Being Removed from Chrome

#36

Post by ejcx »

buu700 wrote: post #34
ejcx wrote: post #33

Earlier quoted context omitted.

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 dangerou…

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 relat…

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

Re: Public Key Pinning Being Removed from Chrome

#37

Post by Laforet »

nly wrote: post #35
sigmar wrote: post #9

Good riddance. It had low adoption and pales in comparison to what will be achieved with Certificate Transparency. DNS redirect attacks (common/easy due to social engr) combined with malicious HPKP could result in some nasty ransoming ("many of your users can't access your site unless you pay me for the key"). I've heard many surprised it hasn't happened yet. Particularly considering the lack of recourse options for…

> DNS redirect attacks (common/easy due to social engr) combined with malicious HPKP could result in some nasty ransoming How? Someone can hijack your resolver but they still need a valid certificate for the name before they can install the pin?

Once an attacker controls a domain it is trivial to get a DV certificate signed with their own key.

Re: Public Key Pinning Being Removed from Chrome

#38

Post by nsgi »

saas_co_de wrote: post #15

why not provide an advanced feature that alerts you any time a cert changes, similar to what we get with SSH? at least then security conscious users could make decisions for themselves.

The user has no realistic way to determine whether a certificate change is legitimate or due to a man-in-the-middle, even if they are technical, unless they are told out-of-band. Normal users are likely to just click through any warnings, because they don't care about security as much as getting their work done, particularly since a warning is almost certainly a false alarm.

Re: Public Key Pinning Being Removed from Chrome

#39

Post by buu700 »

ejcx wrote: post #36
buu700 wrote: post #34

Earlier quoted context omitted.

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 relat…

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

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.

Re: Public Key Pinning Being Removed from Chrome

#40

Post by nly »

Laforet wrote: post #37
nly wrote: post #35

Earlier quoted context omitted.

> DNS redirect attacks (common/easy due to social engr) combined with malicious HPKP could result in some nasty ransoming How? Someone can hijack your resolver but they still need a valid certificate for the name before they can install the pin?

Once an attacker controls a domain it is trivial to get a DV certificate signed with their own key.

Hijacking a authorative DNS server is different kettle of fish to hijacking a resolver used by a client. You need to either infiltrate a CA or do the former for a DNS attack to work and get you a DV certificate.
Post reply on HN