[kinofcain]

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]

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]

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_Pinn... ); I don't know how to do it on Chrome.