TLS and the Policy MitM Armageddon

Kazakhstan has announced that it will be performing Man-in-the-Middle attacks on all HTTPS traffic from the beginning of 2016. Users in Kazakhstan will be forced to install the CA certificate of a rogue CA in order to allow their traffic to be intercepted.

There are several immediate conclusions. Firstly, if Kazakhstan gets away with this, it seems like it's only a matter of time until China, etc. impose this as well.

Secondly, double HTTPS, or HTTPS-inside-an-obfuscation-layer-inside-HTTPS may become useful technologies. Actually, scratch that, Tor's obfsproxy is probably much more applicable.

But thirdly and most importantly, this could have been prevented if the HTTP Public Key Pinning web security extension hadn't been gimped from the beginning. Popular web browsers disable processing of HPKP when a site is accessed using a “custom” CA certificate. This is endorsed by a clause in the HPKP specification. I call this “policy” MitM. It's an increasingly common tactic in corporate networks.

If browser vendors relented on this, and stopped disabling HPKP and treating some CA certificates specially simply because they were manually installed, and backed this up with an extensive HPKP pin preload list, policy attacks like this would become untenable.

In the first place, the efforts by browser vendors to support “policy” MitM, and the incorporation of a getout clause in the HPKP RFC to this end does not align with any design aspect of the web. Nothing about the web is intended to support “policy” MitM. There is no explicit or implicit obligation on the part of browser vendors to make things easy for “policy” MitM adversaries, whether they are corporate or national.

If people want to create a “corporation/state intercept” culture, they're free to do so, but there is no reason why this should be supported by browser vendors. If HPKP preload causes problems for policy MitM adversaries, this is not a browser problem because policy MitM has never been and never will be a supported use case. That browser vendors are encouraging the wholesale adoption of TLS while simultaneously supporting a way to undermine it is hypocritical.

Not long ago I half-jokingly wrote a specification for a “strict” parameter to HPKP, resisting the temptation to call it “no-really-i-mean-it”. The idea is that websites should be able to induce denial-of-service attacks against themselves when a user is the victim of policy MitM. It's sort of like the SOPA internet blackout on steroids.

Google's hypocrisy and exceptionalism. A “strict mode” already exists in Google's Chrome browser. The pinning policy for certain HTTPS requests made by Google cannot be overridden by policy MitM (i.e., the pinning policy for certain requests is not disabled when when the server certificate presented for the connection terminates with a custom trust anchor).

Here's a quote from Google's Chrome knowledgebase:

Domains that have network filtering devices doing SSL inspection generally require a custom Root certificate to be added to the Authorities tab on the Chrome device at chrome://settings/certificates. While this works for most user-driven web requests, some system-level requests do not use this certificate to protect the user against certain kinds of security risks.

To get Chrome devices to work on a network with SSL inspection, you need to whitelist the following hostnames on your proxy server to let these requests to go through without any SSL interception.

accounts.google.com, accounts.gstatic.com, accounts.youtube.com, clients1.google.com, clients2.google.com, clients3.google.com, clients4.google.com, cros-omahaproxy.appspot.com, dl.google.com, dl-ssl.google.com, www.googleapis.com, m.google.com, omahaproxy.appspot.com, safebrowsing-cache.google.com, safebrowsing.google.com, ssl.gstatic.com, tools.google.com, pack.google.com, www.gstatic.com, gweb-gettingstartedguide.appspot.com, storage.googleapis.com, commondatastorage.googleapis.com

So let's get this straight. Pinning works, unless you add a custom trust anchor, in which case it doesn't... except that it still does for certain extra-special Google domains. Apparently, only Google deserves HPKP that actually works. This is exceptionalism of the worst kind; Google is offering itself a special level of connection security that is not offered to other websites.

The “if they have root...” argument. A common argument against doing something about this problem is that if you control the client, you control the client, and that therefore any attempt at security is futile. If the adversary can install software on the client, there is no available countermeasure.

This is objectively true, but it misses the point. The question is not whether strict HPKP enforcement is an effective mitigation against such endpoint control, which it obviously cannot be. The question is why a metaphorical big red “bypass HPKP” button should be installed in web browsers. The argument seems to be that if the big red button was removed, adversaries might use other attacks to accomplish the same end.

This is a strange argument, since it presupposes that the burden of proof is on people agitating for the removal of HPKP policy override rather than the people who want to keep it. The same argument could just as well be used to argue that there is no point in having the override in the first place, since it can be accomplished by other means. What is the premise here, that the override button is some sort of capitulation to policy MitM adversaries in a sort of surrender: “look, we'll give you this, please don't install malware on endpoints?”

Moreover, it oversimplifies the issue. There are likely to be a substantial number of machines on which an adversary is not in a position to install software. Embedded systems, for example, or unjailbroken iOS devices¹. The diversity of computer software and hardware makes mandatory malware a difficult pill to push. A key component of the political feasibility of policy MitM is that users have the option of capitulating to it in the first place. Most users will put up with this by agreeing to capitulate rather than decline to access HTTPS websites at all.

If users have no option to capitulate, however, the political feasibility of this maneuver is severely reduced. Suppose, hypothetically, that Apple updated iOS to strictly enforce HPKP without exception. Naturally they would also deny Kazakhstan access to peddle malware to facilitate the same end. Because the denial of service condition is enforced, the policy MitM imposition maneuver changes from an act of strongarming to an act of simple denial of service. (If denial of service is politically acceptable, they can simply block such traffic outright.)

¹ I do not use or endorse devices which apply restrictive code signing practices, but it is interesting to evaluate the potential utility in this context.

Armageddon. The effort to increase HTTPS adoption is driven by the degree of exploitation now seen against HTTP traffic. Surveillance; exploit packet injection; data mining for advertising; injection of notices by ISPs. This is a general demonstration of the fact that on the internet, anything that can be done by an attacker, will be done, and this must be assumed.

If adversaries can eavesdrop on cleartext traffic, they will. If adversaries can successfully coerce people into installing an illegitimate CA, they will. The fact that this attack involves the human element of installing a certificate does not mean that it is not an attack and it does not mean that it should not be mitigated against.

If these types of attacks are not stopped, they will become so everpresent that they become a given, and thus tolerated, the and there will never be an opportunity to undo that damage. HTTPS will become meaningless.

If the UK government with their recent anti-encryption rhetoric thought they could successfully compel people into installing an illegitimate CA, do you really think they wouldn't? Currently the UK seems to be partly restrained by the (correct) fear that pushing too hard will lead to an exodus of IT investment, and cluelessness as to what is technologically feasible. If the world as a whole increases the network threat level, there will be no alternative economies to flee to and nothing to stop adoption of these policies.

Moreover, the more commonplace these attacks become, the more aware governments become of their feasibility and thus the more likely they become to mandate them. Blocking of “pirate” websites did not happen overnight; it happened gradually, as governments and courts became gradually more aware that yes, it was, in fact, something that could be done, technologically. The number of domain name seizures is also not something that happened instantly, but something that gradually ramped up as the feasibility of such seizures became apparent. This move by Kazakhstan is the beginning, not the end. Stop these attacks in Kazakhstan or they'll soon be coming to a place near you.