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