"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.
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.
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.
The company I work for has a strict policy of no direct outbound connections from the corporate network. This is to prevent (or just make harder) for compromised machines from "phoning home".
This has the unfortunate side effect that all internet traffic must go through a proxy, they have to MiTM SSL traffic.
I just use my smartphone's data for any personal internet browsing.
Well you don't have to MITM SSL in order to proxy it, it can be done in other ways. They probably choose to do so in order to see the details of the request.
Correct, the firewall intercepts all traffic looking for potential compromises and blocks it. Given all these corporations getting hacked, such measures seem necessary.
Conclusion does not follow from premise. Once an attacker's code is running on machines that have access to sensitive data, you've already lost - there's no way to prevent it smuggling the data out in legitimate-looking requests. The right way is to stop the bad stuff getting in in the first place.
btw, I took a look at google's cert in my corp network and we are getting the real one from google, so my corp is not MiTM SSL traffic from some sites right now.
What does your company do if you have to access a TLS site which uses client certificates for authentication? AFAIK, client certificates don't work when there's a MITM on the TLS traffic, since the MITM proxy doesn't have a way to produce a client certificate that will be accepted by the server.
It's called defence in depth. If you can prevent 99% of malware infections and can prevent 75% of malware from phoning home, you have a 99.75% confidence (1 in 400) of not having a data leak due to a compromised machine. That's 4 times better than only preventing infections.
The line between what computing should be done on what device is blurry in both directions -- it's not just "people do personal computing on corporate devices". It'd be a bit strange to hear a boss tell me to never browse Amazon or Hacker News during lunch.
I think it's wise to assume corporate-owned devices are just that: 0wned by corporations.
I use my work laptop all the time for a variety of things, but I do so under the assumption that the company may be snooping on me. (No idea if they are or not.)
Exactly. It's a work machine, used for doing work. I don't do private/personal/secure things on it, as it's not my personal computer. Browsing HN or w/e isn't really a private activity, so I don't mind it being snooped.
I guess I should look into the Chromium source to disable this MITM "feature"... I'm really too busy so if anyone else does this I'd much appreciate a patch.
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."
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.)
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.
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.
"""
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#...