The core problem here is that, although the people who bought the computers did not want a certificate installed that makes MITM attacks easy, the computer vendors sold them that way anyway. The people who bought the computers did not, in effect, really have full ownership of what they bought. Additionally, people did not come to realize this until many months after the computers were sold! (See also Ars Technica’s coverage.)
People who want HPKP to solve the problem wish that, when setting public key pins, servers should be able to expect clients to perform Pin Validation unconditionally — to always obey the server’s requirements, regardless of the client’s configuration. Even, if necessary, taking priority over the requirements of the client machine’s owner. This would be a weak form of Remote Attestation. The goal, in this case, is to make things like the Superfish and Dell certificates ineffective for use in attacks or mischief: the interloper certificates just wouldn’t work, and would hence be discovered immediately.
However, it is not possible for a low-privilege application to defend against the platform it runs on, if the platform is intent on undermining the application’s expectations. To try would be futile, and would necessarily also violate a crucial digital rights principle: The computer’s owner should get to decide how the computer behaves. Dell and Lenovo let their customers down in that way, but for better and for worse, it’s not something that a web browser can fix.
Our idea when designing HPKP was to allow a site to reduce the number of issuers that can issue certificates for the site — assuming the client is not already compromised. We assumed that because we must: as the Chromium Security FAQ and Microsoft’s 10 Immutable Laws Of Security document, if a computer’s operating system is compromised, there is nothing certain that a mere userland application — which must depend on the underlying layers, including the OS — can do.
Specifically, browsers do not perform Pin Validation when the presented certificate chain chains up to a locally-installed, ‘private’, or ‘non-system’ trust anchor. (Microsoft ships a standard set of trust anchors for the system, but also enables the system’s administrators/owners to install additional, local anchors.) There are 3 reasons for this:
All the same, people seem to wish that servers could say to clients, “Here are my expected keys, and you should fail to connect to me if I seem to present different keys, even if the person who owns the computer wants to connect anyway.” That would be beneficial in that non-consensual proxying would be exposed sooner and with somewhat more certainty. But if a server could get such a guarantee, it could also be used in ways very much counter to the open Internet we know and love. Thus, frankly, I’m glad that Remote Attestation is impossible. (Or, if you prefer, so impractical and theoretical as to be impossible for now.)
There are many, many ways in which the higher-privilege operating system or other software can force the lower-privilege client program to connect through a proxy, in spite of a hypothetical ‘strict’ HPKP behavior. Here are a few examples — I don’t imagine this list is exhaustive:
The ironic thing is that, if clients did implement the ‘strict’ form of Pin Validation, many of the same people who are now calling for it would either resort to the above means to do their legitimate proxying, or would buy their proxy software from someone who does.