Live data from Hacker News

Public Key Pinning Being Removed from Chrome

groups.google.com

41–50 of 111 posts

Re: Public Key Pinning Being Removed from Chrome

#41

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…

Why not have it approve an ultimate CA instead? Or least one up in the chain.

Re: Public Key Pinning Being Removed from Chrome

#42

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…

I agree that the utility of this feature would be limited to a small percent of users for a small percent of cases.

The SSH example comes to mind because that is a system that does something similar.

In my experience every single SSH error on a key change has been a false positive but everyone accepts the high false positive rate because it is worth it to detect that one case where you are actually compromised.

Re: Public Key Pinning Being Removed from Chrome

#43
post #32

Earlier quoted context omitted.

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, an…

> We should check when Let'sEncrypt renews by default (is that 14 days before expiry?)

30 days in Certbot defaults, and I think that's an official Let's Encrypt recommendation for authors of other clients.

Re: Public Key Pinning Being Removed from Chrome

#44
post #38

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.

I agree. I wouldn't see this as being for average anonymous users using some mass market service.

It would only be useful in cases where people are willing to pay a price (in convenience) for security, understand the tech well enough to use it, and have some relationship with the domain owner that allows out-of-band verification of cert changes.

Re: Public Key Pinning Being Removed from Chrome

#45
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…

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

Re: Public Key Pinning Being Removed from Chrome

#46
post #39
post #36

Earlier quoted context omitted.

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.

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.

Re: Public Key Pinning Being Removed from Chrome

#47

Earlier quoted context omitted.

Sounds a lot like DANE/TLSA.

Oh cool, haven't read about this one before. Wonder why it didn't get picked up despite being a standard :(

> Wonder why it didn't get picked up despite being a standard :(

It doesn't work on the real internet, only on some fantasy internet that merely exists in the head of DNSSEC advocates.

Basically you can only do DNSSEC if you can receive arbitrary DNS records. That's not the case for a non-negligible portion of Internet accesses, where those queries get filtered. Adam Langley has pointed this out years ago: https://www.imperialviolet.org/2015/01/17/notdane.html

So if you want to deploy DANE you can choose between falling back to insecure (so it's entirely pointless) or breaking the Internet for a large fraction of users. Neither is a very good plan.

Re: Public Key Pinning Being Removed from Chrome

#48
post #11

This is especially funny to me as our PCI DSS Network Scan just started flagging not having a HPKP Header as something thats necessary to remediate. I've had to waste half a day on the phone and then to write a Risk Mitigation Plan that explains how we mitigate the risk of an MITM Attack in case our CA gets breached...

It is deeply fucked up if a scanning checklist demands PKP, since most sites --- including most commerce sites --- shouldn't pin.

Well, try explaining that to the HSTS and HPKP folks. They already have answers littered on stack overflow and HN to advise to enable it for anything and everything. With exactly zero consideration for the potential to backfire.

It's only a matter of time before an intern or an audit guy have it deployed on majorcompany.com and result in a disaster. Symptom includes none of the client ever able to access the site again.

Re: Public Key Pinning Being Removed from Chrome

#49
post #40
post #37

Earlier quoted context omitted.

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.

Once a site is breached, the attacker is usually in control of the domain and he can order any legitimate certificate for it.

Re: Public Key Pinning Being Removed from Chrome

#50
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…

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.
Post reply on HN