Noncombatant đ About âïž Other Writing đ” Bandcamp đ» GitHub
Every time something like this happens (...again), people start clamoring for public key pinning to âsolveâ the problem.
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.