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

51–60 of 111 posts

Re: Public Key Pinning Being Removed from Chrome

#51

Post by user5994461 »

lucb1e wrote: post #32
PhantomGremlin wrote: post #20

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…

The big sites have multiple certificates for a single domain and you will get one randomly depending on what server you happen to it.

Re: Public Key Pinning Being Removed from Chrome

#52

Post by technion »

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.

You can always monitor for any time a cert is issued on your own domains. Couple that with Expect-CT and you have something as good as HKPK, without the downside.

(Disclaimer: I run an open source monitoring project)

Re: Public Key Pinning Being Removed from Chrome

#53

Post by abarringer »

Roritharr wrote: post #2

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

Are you using Qualys? It seems they are having major issues with header checks starting around Oct 1st. Tenable however still passes sites without HPKP. Getting our vendors, like fortinet, to implement all the security headers Qualys now demands will be impossible so we are checking other ASV's to see how they respond to our sites. Just for jollies you should go check pci.qualys.com's security headers.

Re: Public Key Pinning Being Removed from Chrome

#54

Post by eganist »

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

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.

Re: Public Key Pinning Being Removed from Chrome

#55

Post by ejcx »

eganist wrote: post #54
ejcx wrote: 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

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.

Re: Public Key Pinning Being Removed from Chrome

#56

Post by amalcon »

rocqua wrote: post #24
mschuster91 wrote: post #17

Earlier quoted context omitted.

> What would be the fix? I'm asking sincerely as someone who is only surface level familiar with HPKP, and have never implemented it (but my boss did...) The fix would be to embed the expected key fingerprint in DNS and have the browser issue either a 2nd request for it or have the DNS server return it as additional data just like when requesting a CNAME record and it returns the A record too. Then, to prevent DNS MI…

As the other commenter said, this sounds a lot like DANE. As such, it suffers from the same issue: it relies on DNSSEC. If you look at the trust chain for DNSSEC on the .com domain, you are trusting the US government and your registrar. The US government is the bigger issue here, as the NSA is also a part of them. You might argue that this is 'good enough' but considering the momentum that these kind of systems have,…

This has always seemed like a really silly argument. You're already trusting the US government, VeriSign, and a multitude of other organizations that control CAs, so DANE doesn't make this worse.

It's kind of a moot point, though, since DNSSEC is garbage for other reasons. Certificate transparency logs are the current best effort in this area.

Re: Public Key Pinning Being Removed from Chrome

#57

Post by alpb »

As someone who's completely unfamiliar with the Chrome ecosystem I wonder what Blink has anything to do with this (why is this posted in blink-dev@googlegroups.com)? Isn't Blink just the rendering engine for Chromium that does DOM/CSS stuff?

Re: Public Key Pinning Being Removed from Chrome

#59

Post by dane-pgp »

rocqua wrote: post #25
mschuster91 wrote: post #23

Earlier quoted context omitted.

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

The basic reason is that people really don't like DNSSEC. tptaeck ( https://news.ycombinator.com/user?id=tptacek ) has plenty of comments really supporting that argument.

I won't say he's wrong, but he presents a very one-sided view. It's worth reading the responses to criticisms like his:

https://www.easydns.com/blog/2015/08/06/for-dnssec/

Re: Public Key Pinning Being Removed from Chrome

#60

Post by eganist »

Roritharr wrote: post #2

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

https://twitter.com/eganist/status/920399513638133761

Glad there are more reports of this showing up.

Post reply on HN