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

81–90 of 111 posts

Re: Public Key Pinning Being Removed from Chrome

#81

Post by rocqua »

amalcon wrote: post #56
rocqua wrote: post #24

Earlier quoted context omitted.

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.

The point is not that DANE doesn't make things worse. The point is that it is not a solution. Originally, DANE was meant as a method to restrict rogue CA's from issuing certificates. The fact that state-actors can still do that after DANE makes DANE a bad solution.

Re: Public Key Pinning Being Removed from Chrome

#83

Post by jakub_g »

jkooper wrote: post #67

Is there an alternative to prevent people from doing MITM attacks on mobile apps? With HPKP running, apps with Charles requires a rooted device.

For mobile apps it's easier than for websites because native apps have more control over what's going on than the website, and can read the details of http connections (so in worst case, you can roll out your own pinning).

For Android there are a built-in facilities for that in modern versions: https://developer.android.com/training/articles/security-con...

For iOS: not an expert, but this article seems good https://dzone.com/articles/ssl-certificate-pinning-in-ios-ap...

It might get a bit trickier when WebViews are involved though because, at least on Android, SSL in WebView is subject to different security rules than the java-initiated connections (AFAIU the problems due to https://www.chromium.org/developers/androidwebview/webview-c... could not have been avoided on the app side, for example, as it was a bug in Chromium).

Re: Public Key Pinning Being Removed from Chrome

#84

Post by daira »

saas_co_de wrote: post #42
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…

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.

But you don't detect that one case where you are actually compromised. You dismiss it like you do all the false positives. At best, when you get pwned you think back to having dismissed the key change warning and know what happened, but how does that actually help you?

Re: Public Key Pinning Being Removed from Chrome

#85

Post by wolf550e »

alpb wrote: post #57

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?

They used to coordinate security stuff on mozilla.dev.security.policy but they switched to blink-dev, maybe to indicate this is Chrome's/Google's position only. The first big use of blink-dev for security that I remember was the Symantec thing.

Re: Public Key Pinning Being Removed from Chrome

#86

Post by AndyMcConachie »

rocqua wrote: post #80
AndyMcConachie wrote: post #78

Earlier quoted context omitted.

I don't understand this US government nonsense and why it continues to persist. Will someone please explain to me like I'm 5 why you are trusting the US government if you deploy DNSSEC? Where in the trust chain of the .com zone does the USG come into play?

The .com domain is controlled by the USG. If they want to serve a false DNS response, they can access the key used to sign the .com domain. That key can be used to sign a new key for the relevant domain, which can be used to sign the response. That the .com domain is under USG controll follows from: "The domain was originally administered by the United States Department of Defense, but is today operated by Verisign,…

Verisign is just a company located in the USA. Does it then follow that any company located in the USA is 'controlled by the USG'? That seems like a bit of a stretch, to say the least. There is nothing else there. Your reference to history is irrelevant today.

Also, I really don't understand what this has to do with DNSSEC? Without DNSSEC anyone can forge responses. With DNSSEC you limit that to the zone administrator.

Re: Public Key Pinning Being Removed from Chrome

#87

Post by Exuma »

toast0 wrote: post #72
Exuma wrote: post #68

Earlier quoted context omitted.

That's an amazingly AWESOME answer, thank you. So... what's an example of a CA that the most highest value targets on the internet trust? (like Google, Facebook, Amazon, and various banks). Is there like a very trustworthy company that handles most of the big companies?

There's a list of pinned CAs at the top of the hsts preload list [1]. Which gives you an idea of who might be trusted. Cert pinning is pretty nasty if you get it wrong. If you don't pin, there's a large number of CAs in most client's default trust stores. If you do pin, and the CA you pinned turns out to be bad, it didn't help. If you pin, but the CA stops issuing from the intermediate or the root that you pinned, yo…

Maybe this is a dumb question... but do larger companies like Google attempt to set up their own CA so they can be sure of the longevity and security, and not rely on a 3rd party?

Re: Public Key Pinning Being Removed from Chrome

#88

Post by scott00 »

daira wrote: post #84
saas_co_de wrote: post #42

Earlier quoted context omitted.

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.

But you don't detect that one case where you are actually compromised. You dismiss it like you do all the false positives. At best, when you get pwned you think back to having dismissed the key change warning and know what happened, but how does that actually help you?

I actually caught a semi-real one once. My new employer was MITMing all ssh traffic.

Re: Public Key Pinning Being Removed from Chrome

#89

Post by rav »

jakub_g wrote: post #82
_Codemonkeyism wrote: post #75

The same as with 301, everyone recoomends them until they buy a domain or do some restructuring with new people some years down the line and 301 totally messed their site up without any reset button.

Can you explain this more?

HTTP provides a couple of different response codes for when one URL should redirect to another URL. The most common are 301 Moved Permanently and 302 Found, aka moved temporarily.

When designing a website and you find the need to redirect one URL to another, you have to choose which HTTP response code to use for the redirect. You might naively think 301 Moved Permanently is the right choice for when you perceive the redirection to be a non-temporary thing. Unfortunately HTTP 301 responses are cached very aggressively by web browsers by default, so if you install a 301 redirect in your website and choose to revert it, clients who have already seen the now-reverted 301 redirect will just keep following the cached redirect.

Basically, unless the URL you're redirecting is receiving way more than a thousand hits per second (i.e. unless you're running a large-scale website with lots of traffic), you should always use the temporary 302 redirect, even though you might perceive the redirection to be non-temporary.

Re: Public Key Pinning Being Removed from Chrome

#90

Post by peterwwillis »

Ah, Google. The tech gods giveth standards, and the tech gods taketh standards away.

This is what happens when you let a single vendor define web standards, and have a majority share of the browser market. They can take their toys and go home, and websites won't support what they don't support.

Post reply on HN