Public key pinning coming in Chrome 13 | Hacker News Reader

Public key pinning coming in Chrome 13

imperialviolet.org

68 pointstrotsky15 comments

Summary: the CA system is so broken that Google decided to hardcode a small list of CAs for google.com etc. "High value sites" can request the same treatment.

I was excited for this until I read that user-installed root CAs are allowed to override the pinning. I suppose it's still a good development though.

Truly. Malware will just install user defined root CAs and you will be exploited that way.

Or it could just fiddle with the browser directly. Why is trusting explicitly user-supplied CAs such a bad thing?

He has the thread model backwards. If your advisary already can modify files on your computer, you have other things to worry about than SSL being compromised through the network.

The malware could just as well intercept your data before it is encrypted, for example, by installing a rogue SSL library. No need for sniffing and fake certs.

Securing the data in transit and securing it on a device are two different concerns and it seems silly to expect a network protocol to be able to secure against scenarios where malware is at play.

If you're infected with malware, just patch Chrome in memory to report everything as SSL connected, etc. If you're already compromised, nothing Google can do can help you.

I was thinking the exact opposite. Many organizations (especially the govt) rely on SSL proxies like BlueCoat that effectively hijack SSL traffic with on the fly generated SSL certs from a trusted organizational CA, in order to inspect/filter outbound data. 'Pinning' would totally destroy this capability if organizational CA's couldn't override it.

I don't understand. I am sure I am missing something obvious but maybe you can help me understand.

The purpose of STS is to avoid the user accidentally going to the http address of a page instead of the https page. This is achieved by a special HTTP header that is sent from the server to the browser. The browser remembers that the server wishes to be contacted only over https, and from that moment on all network traffic from the browser to that domain will only be possible over https. No way for the user to accidentally type http://gmail.com/.

How is this different from a 302 location redirect header from the http:// url to the https:// url?

An attacker could intercept that initial http:// url and provide their own destination for the browser to visit instead. HSTS prevents this from happening once the domain is in the cache (or pre-loaded).

An attacker that is able to MITM your traffic or poison your DNS can steal your session before you ever get to the trusted https url.

http://www.thoughtcrime.org/software/sslstrip/

But that is a problem with STS too. That is why google is HSTS preloading a lot of google domains in their browser (they hardcode the domains). Couldn't they just hardcode the redirect so that if the user types http://gmail.com/ chrome replaces it with https://gmail.com?

STS solves the problem unless the attacker has a fraudulent certificate for the domain you are reaching that is signed by a CA you trust. Presumably this is far fewer attackers than those who could manipulate your DNS or are on your local network to ARP in as a middleman. Basically, two different problems - the trust only X CA for xxx.com wouldn't ever get to come into play if someone using sslstrip simply keeps you from ever going to tls.

It's a problem with STS the first time the browser visits a particular site. Once the browser receives the STS header, all future requests to that site will be over HTTPS.

If an attacker controls DNS (which is doable), he could just not issue the redirect and you'd happily tell your GMail password to his server.

Also, redirecting from e.g. http://gmail.com/login?user=me&pass=secret to https://gmail.com/login?user=me&pass=secret is not that useful, so this can also help with some forms.

Why don't we make Perspectives standard and just be done with it?

Reply on news.ycombinator.com