4 ms·

Public key pinning coming in Chrome 13

68 points by trotsky 15y ago

JoachimSchipper 15y ago
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.
xiaomai 15y ago
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.
- pyre 15y ago
  Truly. Malware will just install user defined root CAs and you will be exploited that way.
  - JoachimSchipper 15y ago
    Or it could just fiddle with the browser directly. Why is trusting explicitly user-supplied CAs such a bad thing?
    - wladimir 15y ago
      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.
  - drivebyacct2 15y ago
    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.
- count 15y ago
  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.
StavrosK 15y ago
Why don't we make Perspectives standard and just be done with it?
y0ghur7_xxx 15y ago
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/ http://gmail.com/. How is this different from a 302 location redirect header from the http:// http:// url to the https:// https:// url?
- EricButler 15y ago
  An attacker could intercept that initial http:// 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).
- trotsky 15y ago
  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/ http://www.thoughtcrime.org/software/sslstrip/
  - y0ghur7_xxx 15y ago
    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/ http://gmail.com/ chrome replaces it with https://gmail.com https://gmail.com?
    - trotsky 15y ago
      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.

68 points by trotsky 15y ago

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.

xiaomai 15y ago

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.

pyre 15y ago
Truly. Malware will just install user defined root CAs and you will be exploited that way.
- JoachimSchipper 15y ago
  Or it could just fiddle with the browser directly. Why is trusting explicitly user-supplied CAs such a bad thing?
  - wladimir 15y ago
    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.
- drivebyacct2 15y ago
  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.
count 15y ago
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.

StavrosK 15y ago

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

y0ghur7_xxx 15y ago

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/ http://gmail.com/. How is this different from a 302 location redirect header from the http:// http:// url to the https:// https:// url?

EricButler 15y ago
An attacker could intercept that initial http:// 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).
trotsky 15y ago
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/ http://www.thoughtcrime.org/software/sslstrip/
- y0ghur7_xxx 15y ago
  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/ http://gmail.com/ chrome replaces it with https://gmail.com https://gmail.com?
  - trotsky 15y ago
    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.