Public Key Pinning Being Removed from Chrome • Hacker News Board

Re: Public Key Pinning Being Removed from Chrome

#71

Post by lucaspiller » Sat, Oct 28, 2017, 6:18 AM UTC

user5994461 wrote: post #48

tptacek wrote: post #11

Earlier quoted context omitted.

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

Last year I was contracting at an NGO where somebody decided to add our domain to an HSTS preload list. This worked great for the public facing site, which was already served over HTTPS, but we also had a load of internal apps on the same domain.

They were only accessible from our network (ethernet or VPN), so we hadn’t bothered with HTTPS before. Oh and we only found out about the issue when Chrome updated and everything broke - it was a fun few days!

Re: Public Key Pinning Being Removed from Chrome

#72

Post by toast0 » Sat, Oct 28, 2017, 6:36 AM UTC

Exuma wrote: post #68

dfabulich wrote: post #64

Earlier quoted context omitted.

On the internet, when you send and receive data, your data gets handled by a lot of different people. In the old days, anybody who handled your data could tamper with it or impersonate anybody else. Cryptography to the rescue. Suppose "Alice" and "Bob" want to send secret messages to each other, without allowing "Eve" the eavesdropper to read them, even if Eve can intercept the messages. Traditional cryptography is "…

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, you can't get a new cert (hope you had other options); note that CAs don't give much guidance about what to pin. If you pinned a CA that gets delisted, that's no good either. If you pinned two different CAs (a smart choice), but they merge, you no longer have a backup. So, you should pin a public key that you haven't gotten a cert with yet, and keep it safe,but also readily available for emergencies. But you only get one emergency -- hope your next emergency comes after you have time to figure out new pins and get them bundled everywhere; and in the meantime you have one key for everything, which isn't great.

(Based only on the name) Expect-CT doesn't provide nearly as much protection, any CA cert will work, but only if it was publicly recorded. If you monitor for certs issued on your domains, at least you know to raise a fuss if a CA you didn't authorize issues on your domains. That's probably enough to keep CAs in line, unless Let's Encrypt drives the net present value of a well distributed CA to below the value of illicit certificates.

[1] https://chromium.googlesource.com/chromium/src/net/+/master/...

Re: Public Key Pinning Being Removed from Chrome

#73

Post by hsivonen » Sat, Oct 28, 2017, 7:09 AM UTC

Seems reasonable to remove HPKP.

In my experience the use case that HPKP addresses the best is winning arguments with people who like ssh and think WebPKI and browsers are wrong. HPKP can be used to establish TOFU trust in the leaf key (but you need to pin your future key, too).

Winning that argument isn't worth the risks of HPKP, though.

Re: Public Key Pinning Being Removed from Chrome

#74

Post by pfg » Sat, Oct 28, 2017, 7:30 AM UTC

jopsen wrote: post #69

MichaelMoser123 wrote: post #66

Kazakhstan and probably Russia as well require all TLS traffic to be opened by MITM devices. https://m.habrahabr.ru/post/303736/ https://news.ycombinator.com/item?id=10663843 https://www.google.co.il/amp/s/www.rbth.com/document/1033000... i wonder if other governments are enacting similar rules in one form or the other....

That sounds hard to implement. If it's done by issuing a new certificate for a different key then won't it trigger red flags when certificate transparency becomes mandatory? Resulting in the CA getting the kick.

IIRC the plan was to force users to manually install a root certificate (controlled by the government) on their devices. Local roots are exempt from any CT enforcement. Naturally, you can just not install the root certificate, but if all traffic is intercepted, I'd expect most users to do so to get around the warnings.

Re: Public Key Pinning Being Removed from Chrome

#75

Post by _Codemonkeyism » Sat, Oct 28, 2017, 8:12 AM UTC

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.

Re: Public Key Pinning Being Removed from Chrome

#76

Post by ComodoHacker » Sat, Oct 28, 2017, 8:30 AM UTC

Without key pinning, are threre other options for site operators to protect their users from MITM by traffic monitoring appliances?

Re: Public Key Pinning Being Removed from Chrome

#77

Post by andyjh » Sat, Oct 28, 2017, 8:51 AM UTC

darkhorn wrote: post #10

What about supporting client side certificates in HTTP2?

You can use client certificates in h2, you just can't do TLS renegotiation. So you have to request a client cert in the initial handshake; you can't ask later (eg for a specific URL).

Re: Public Key Pinning Being Removed from Chrome

#78

Post by AndyMcConachie » Sat, Oct 28, 2017, 9:26 AM UTC

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

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?

Re: Public Key Pinning Being Removed from Chrome

#79

Post by Buge » Sat, Oct 28, 2017, 9:33 AM UTC

user5994461 wrote: post #48

tptacek wrote: post #11

Earlier quoted context omitted.

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

HSTS should never result in "none of the client ever able to access the site again".

Re: Public Key Pinning Being Removed from Chrome

#80

Post by rocqua » Sat, Oct 28, 2017, 11:16 AM UTC

AndyMcConachie wrote: post #78

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

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, and remains under ultimate jurisdiction of U.S. law."[1] That said, since the control was transfered away from the DoD, the control is much less.

A similar argument still holds for country level TLDs. Any government that administers its own TLD can use that with DNSSEC to forge DNS responses.

[1] https://en.wikipedia.org/wiki/.com