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

101–110 of 111 posts

Re: Public Key Pinning Being Removed from Chrome

#101

Post by saas_co_de »

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?

this does not follow at all. any time a cert has changed i either know the cause or verify the cause before using the server.

Re: Public Key Pinning Being Removed from Chrome

#102

Post by Panino »

AndyMcConachie wrote: post #86
rocqua wrote: post #80

Earlier quoted context omitted.

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

> 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'?

Verisign doesn't own .com -- the US government does. Verisign operates .com on contract with the US Chamber of Commerce.

Re: Public Key Pinning Being Removed from Chrome

#103

Post by user5994461 »

riffraff wrote: post #100
user5994461 wrote: post #48

Earlier quoted context omitted.

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…

does HSTS have potential to backfire?

The browser will completely block access to the site on any certificate issue. In practical terms, HSTS removes the "ignore certificate error" button that everyone got used to click.

It will backfire when the certificate expires, when some clients don't recognize the CA chain, when domains or subdomains don't match the certificate.

Re: Public Key Pinning Being Removed from Chrome

#104

Post by tptacek »

riffraff wrote: post #100
user5994461 wrote: post #48

Earlier quoted context omitted.

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…

does HSTS have potential to backfire?

Unless you're a static content site that is using TLS just to be an Internet Good Citizen to prevent passive traffic analysis, you absolutely should have HSTS enabled; it's not really a judgement call. Without HSTS, you almost might as well not do TLS at all; HSTS prevents a serious, effective, and easy attack.

By way of comparison, it has never been a good idea to default to HPKP. Privacy-sensitive sites should be pinned, and if you can't safely manage pinning, that's a pretty good sign that you're not mature enough to engineer privacy for the site either, so I don't have that much sympathy for the argument that it's a foot cannon (this is, of course, very easy for me to say). But if you're just selling coffee beans or scheduling laundry pickups, PKP has always been a very bad idea for you.

Re: Public Key Pinning Being Removed from Chrome

#105

Post by Buge »

lmm wrote: post #94
Buge wrote: post #79

Earlier quoted context omitted.

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

HPKP can, if you pin a key and then lose the key you pinned.

I know. But you shouldn't lump the dangerousness of HPKP on HSTS.

Also with HPKP you shouldn't just pin one key. You should pin several keys you own as well as several root and intermediate keys. But I agree it's very difficult to do right and there's still a risk of it failing.

Re: Public Key Pinning Being Removed from Chrome

#106

Post by jopsen »

pfg wrote: post #74
jopsen wrote: post #69

Earlier quoted context omitted.

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.

That probably only works if the root cert is mandated in all OEM installs...

And still you probably won't find any Linux distros with this support.

Note. incepting all traffic sounds expensive and very dangerous, ie. risk or leaking grows when you scale. It's probably better to only use it for select users.

Curious, why future versions of chrome would not force CT for official TLDs?

Re: Public Key Pinning Being Removed from Chrome

#107

Post by pfg »

jopsen wrote: post #106
pfg wrote: post #74

Earlier quoted context omitted.

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.

That probably only works if the root cert is mandated in all OEM installs... And still you probably won't find any Linux distros with this support. Note. incepting all traffic sounds expensive and very dangerous, ie. risk or leaking grows when you scale. It's probably better to only use it for select users. Curious, why future versions of chrome would not force CT for official TLDs?

> Curious, why future versions of chrome would not force CT for official TLDs?

This would cause all corporate MitM proxies to fail. Certificates generated by these devices cannot be logged to the CT log servers accepted by browsers (they only accept certificates chaining back to a trusted root). Local roots were exempt from HPKP pins as well, so this is just keeping with existing policy.

Re: Public Key Pinning Being Removed from Chrome

#108

Post by lmm »

rocqua wrote: post #98
lmm wrote: post #95

Earlier quoted context omitted.

The US Government is and should be the root of trust for US domains (certainly for .us, and de facto that's become the use of .com too). Since the US government can compel any US entity to follow secret orders, if you don't trust the US government you already couldn't use any US sites. DANE improves things compared to not, since it means you don't have to trust the US government if you're not using US sites, you don'…

I am a dutch citizen and have a .nl domain. Yet, that does not mean I am ok with the dutch government issuing invalid certificates for my website. True, it's an improvement that only the dutch government can do this, and not the Hong Kong post office. On the other hand, it is a major downside that we are encoding the possibility of government dragnet surveillance. In the end, certificate transparency logs will let me…

> it is a major downside that we are encoding the possibility of government dragnet surveillance.

Quite the opposite; DANE makes it possible to have a TLD that opts out of giving national governments access to it. Most existing TLDs are controlled by governments, but that doesn't have to be how it is.

Re: Public Key Pinning Being Removed from Chrome

#109

Post by majewsky »

tptacek wrote: post #104
riffraff wrote: post #100

Earlier quoted context omitted.

does HSTS have potential to backfire?

Unless you're a static content site that is using TLS just to be an Internet Good Citizen to prevent passive traffic analysis, you absolutely should have HSTS enabled; it's not really a judgement call. Without HSTS, you almost might as well not do TLS at all; HSTS prevents a serious, effective, and easy attack. By way of comparison, it has never been a good idea to default to HPKP. Privacy-sensitive sites should be p…

Why does being a static content site mean you should not enable HSTS? If anything, HSTS is easiest to roll out for static content sites.

Re: Public Key Pinning Being Removed from Chrome

#110

Post by AfroThundr »

majewsky wrote: post #109
tptacek wrote: post #104

Earlier quoted context omitted.

Unless you're a static content site that is using TLS just to be an Internet Good Citizen to prevent passive traffic analysis, you absolutely should have HSTS enabled; it's not really a judgement call. Without HSTS, you almost might as well not do TLS at all; HSTS prevents a serious, effective, and easy attack. By way of comparison, it has never been a good idea to default to HPKP. Privacy-sensitive sites should be p…

Why does being a static content site mean you should not enable HSTS? If anything, HSTS is easiest to roll out for static content sites.

One primary example would be sites like software repository mirrors, where the majority of content is signed already, and serving them over HTTPS provides negligible benefit to your users (other than the slight confidentiality increase in that an adversary wouldn't know what exactly you downloaded), as opposed to a site serving active content like JavaScript and CSS, which can have disastrous results to the users if an adversary tampers with them.

The latter example is where HSTS becomes an invaluable tool, since now the only way those resources could be delivered is through a trusted channel, verified by the PKI. The same value is not there for a software mirror, because of the other security safeguards already implemented, removing the need to trust the delivery channel. That said, most still do server their content over HTTPS as well.

Post reply on HN