5 ms·

I find it a bit weird that it can MITM https://www.google.com/ https://www.google.com/ on Chrome. I thought Chrome did CA-pinning for Google-domains.

schoen 12y ago
Maybe it triggers the logic that allows (supposedly) user-added certs to override those pins? (Google was pressured into adding such logic by corporate users, whose IT departments want to -- supposedly openly -- MITM employees' connections.) Edit: I think that's the case. AGL's original announcement of pinning said: "There are a number of cases where HTTPS connections are intercepted by using local, ephemeral certificates. These certificates are signed by a root certificate that has to be manually installed on the client. Corporate MITM proxies may do this, several anti-virus/parental control products do this and debugging tools like Fiddler can also do this. Since we cannot break in these situations, user installed root CAs are given the authority to override pins. We don't believe that there will be any incompatibility issues." https://www.imperialviolet.org/2011/05/04/pinning.html https://www.imperialviolet.org/2011/05/04/pinning.html If Chrome thinks that this was a "user installed root CA", it would have been allowed to override the pin. (Disclaimer: I haven't checked that this is right, I'm just using my recollection of how this could work according to AGL's account.)
- edohyiez 12y ago
  Ah, That explains it. Thanks! And to semenko too.
  - schoen 12y ago
    It points to an interesting problem that, while browser vendors officially think that users ought to be notified when someone is using an intercepting proxy -- that it shouldn't be invisible to them -- when users aren't installing their own OS or configuring their own browser, it could be completely invisible in practice. So the IT department-installed or OEM-installed cert is treated as "user-installed" by the pinning logic, and the user never actually gets warned.
    - justcommenting 12y ago
      As someone who respects your work, I would suggest that perhaps the more interesting problem is EFF's structural inability to do anything but apologize for Google policies and practices that clearly and obviously harm user freedom and privacy.
- lazyjones 12y ago
  > Google was pressured into adding such logic by corporate users, whose IT departments want to -- supposedly openly -- MITM employees' connections "openly"? Why doesn't the user see that a fake certificate is being used then? There is no excuse for not showing a big fat warning. This only shows which side Google is really on when it's evil corporations vs. you, the user.
  - deleted 12y ago
    [deleted]
  - beagle3 12y ago
    "openly" usually means "it was burried in a paragraph on page 25 of the 3rd addendum of their employment agreement".
semenko 12y ago
Chrome does do pinning, but ignores pins when the cert parent is a privately installed cert (because this is a "feature" used by many enterprises). """ Chrome does not perform pin validation when the certificate chain chains up to a private trust anchor. A key result of this policy is that private trust anchors can be used to proxy (or MITM) connections, even to pinned sites. 'Data loss prevention' appliances, firewalls, content filters, and malware can use this feature to defeat the protections of key pinning. """ See: http://www.chromium.org/Home/chromium-security/security-faq#TOC-How-does-key-pinning-interact-with-local-proxies-and-filters- http://www.chromium.org/Home/chromium-security/security-faq#...
- kinofcain 12y ago
  And the rationale: "We deem this acceptable because the proxy or MITM can only be effective if the client machine has already been configured to trust the proxy’s issuing certificate" I think that's fair, or at least it has traditionally been a fair assumption for most users. The issue here is that your hardware vendor has compromised your machine, so that is no longer a fair assumption.
  - MichaelGG 12y ago
    Well continue the process. Suppose Chrome did flag such things. That'd break a lot of "legitimate" use cases, and someone would implement a workaround. For instance, they could just patch the Chrome binaries to disable the warnings or change the pinning logic. Insert their own certs into the pin list. Without something like Intel SGX, you or Google can't totally win. Of course, Chrome could give some indication like a lock+eyeball or something, and hope the interception vendors are too lazy to bother modifying the code. They could also only disable warnings if the machine is connected to a domain or other management system.
  - cesarb 12y ago
    There's another issue with ignoring cert pining with user-added root certificates: if you add a root certificate that's missing on your client machine (for instance CAcert or your national CA like ICP-Brasil), the CA you added can bypass pining, even though it shouldn't be able to. On Mozilla, you can configure it to never bypass pining (security.cert_pinning.enforcement_level set to 2, see https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinn... ); I don't know how to do it on Chrome.

schoen 12y ago

Maybe it triggers the logic that allows (supposedly) user-added certs to override those pins? (Google was pressured into adding such logic by corporate users, whose IT departments want to -- supposedly openly -- MITM employees' connections.) Edit: I think that's the case. AGL's original announcement of pinning said: "There are a number of cases where HTTPS connections are intercepted by using local, ephemeral certificates. These certificates are signed by a root certificate that has to be manually installed on the client. Corporate MITM proxies may do this, several anti-virus/parental control products do this and debugging tools like Fiddler can also do this. Since we cannot break in these situations, user installed root CAs are given the authority to override pins. We don't believe that there will be any incompatibility issues." https://www.imperialviolet.org/2011/05/04/pinning.html https://www.imperialviolet.org/2011/05/04/pinning.html If Chrome thinks that this was a "user installed root CA", it would have been allowed to override the pin. (Disclaimer: I haven't checked that this is right, I'm just using my recollection of how this could work according to AGL's account.)

edohyiez 12y ago
Ah, That explains it. Thanks! And to semenko too.
- schoen 12y ago
  It points to an interesting problem that, while browser vendors officially think that users ought to be notified when someone is using an intercepting proxy -- that it shouldn't be invisible to them -- when users aren't installing their own OS or configuring their own browser, it could be completely invisible in practice. So the IT department-installed or OEM-installed cert is treated as "user-installed" by the pinning logic, and the user never actually gets warned.
  - justcommenting 12y ago
    As someone who respects your work, I would suggest that perhaps the more interesting problem is EFF's structural inability to do anything but apologize for Google policies and practices that clearly and obviously harm user freedom and privacy.
lazyjones 12y ago
> Google was pressured into adding such logic by corporate users, whose IT departments want to -- supposedly openly -- MITM employees' connections "openly"? Why doesn't the user see that a fake certificate is being used then? There is no excuse for not showing a big fat warning. This only shows which side Google is really on when it's evil corporations vs. you, the user.
- deleted 12y ago
  [deleted]
- beagle3 12y ago
  "openly" usually means "it was burried in a paragraph on page 25 of the 3rd addendum of their employment agreement".

semenko 12y ago

Chrome does do pinning, but ignores pins when the cert parent is a privately installed cert (because this is a "feature" used by many enterprises). """ Chrome does not perform pin validation when the certificate chain chains up to a private trust anchor. A key result of this policy is that private trust anchors can be used to proxy (or MITM) connections, even to pinned sites. 'Data loss prevention' appliances, firewalls, content filters, and malware can use this feature to defeat the protections of key pinning. """ See: http://www.chromium.org/Home/chromium-security/security-faq#TOC-How-does-key-pinning-interact-with-local-proxies-and-filters- http://www.chromium.org/Home/chromium-security/security-faq#...

kinofcain 12y ago
And the rationale: "We deem this acceptable because the proxy or MITM can only be effective if the client machine has already been configured to trust the proxy’s issuing certificate" I think that's fair, or at least it has traditionally been a fair assumption for most users. The issue here is that your hardware vendor has compromised your machine, so that is no longer a fair assumption.
- MichaelGG 12y ago
  Well continue the process. Suppose Chrome did flag such things. That'd break a lot of "legitimate" use cases, and someone would implement a workaround. For instance, they could just patch the Chrome binaries to disable the warnings or change the pinning logic. Insert their own certs into the pin list. Without something like Intel SGX, you or Google can't totally win. Of course, Chrome could give some indication like a lock+eyeball or something, and hope the interception vendors are too lazy to bother modifying the code. They could also only disable warnings if the machine is connected to a domain or other management system.
- cesarb 12y ago
  There's another issue with ignoring cert pining with user-added root certificates: if you add a root certificate that's missing on your client machine (for instance CAcert or your national CA like ICP-Brasil), the CA you added can bypass pining, even though it shouldn't be able to. On Mozilla, you can configure it to never bypass pining (security.cert_pinning.enforcement_level set to 2, see https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinn... ); I don't know how to do it on Chrome.