Monday, December 04, 2017

Two ways ISPs can do content-based filtering of encrypted traffic

Vaguely a propos of the revived net neutrality debate, a while back I saw someone on Twitter claim that it is technically not possible for ISPs to do content-based (as opposed to destination-based) filtering of SSL traffic. This statement seems initially plausible, but is false. I can think of two technical mechanisms to do content-based filtering.

First, it is possible to identify encrypted content via traffic analysis. ISPs could compile a database of traffic signatures which they wish to throttle (e.g., for videos that are available from their own video streaming services) and throttle any traffic matching that signature.

Second, ISPs can require that users add a trusted SSL root cert owned by the ISP, thus allowing the ISP to man-in-the-middle all SSL traffic. Obviously, content-based filtering then becomes trivial.

You might object that this second measure would be unacceptably onerous, and would be rejected by the market. In the near future, a middle-class American family of four may own ten or twenty Internet-connected devices, running a half-dozen operating systems, and demanding that users install a root cert on all of them would cause unbelievable inconvenience and outcry. This might be true, but without even trying very hard I can think of numerous ways that ISPs could try to acclimate users to this bitter pill:

  • Of course, the software package would be named something relatively innocuous, like "Comcast Internet Security Accelerator" or some such nonsense.
  • The MITM cert might only be required for devices that wish to access the "fast lane" — in other words, the ISP would simply throttle any SSL connection that it does not MITM. All the household's devices would be functional even if you didn't jump through this hoop, but the ones that need the fastest connections — say, the PC that streams HD VR video — would require the MITM cert installation.
  • The ISP could distribute web browsers and other apps that embed the trusted cert — for example, Comcast could provide a custom build of Chromium — and require their use for the "fast lane". Again, you wouldn't need this app for casual web browsing, only for sites that are sensitive to speed.
  • ISPs could strike distribution deals with mobile carriers to install root certs on phones. The most obnoxious way to do this would be to ship the phone's ROM with the MITM cert baked in; this would probably cause massive outcry, akin to the eDellRoot debacle. A sneakier way to do it would be to ship a carrier-branded app that has the ability to update the trusted cert store (by itself this is arguably innocuous), along with an ISP-branded app that (a) nags the user for consent when it detects that the phone is on the ISP's network, something like "Welcome to Comcast! Do you want to enable Comcast Fast Lane[TM]?", and (b) when the user "consents", installs the MITM root cert by delegating to the carrier's app.
  • ISPs could embed a web browser connected to a virtualized display in the set-top box. The set-top box, of course, would already trust the MITM cert. Then, instead of browsing directly to or whatever, you would first browse to http://xfinity.local/, which would present you with a web app that is itself a browser running via remote desktop protocol. Then you would type into the address bar of this web browser. The ISP could even "helpfully" set up its DNS to perform this redirection automatically (if you type without the https).

These are just the ideas that occur to me in about twenty minutes of thinking. If these seem farfetched to you, there may be other ways to boil this frog. Companies can be rather creative when there are billions of dollars of rents to be extracted. The result does not have to be low-cost or seamless for the user; local broadband ISPs in the United States are subject to practically no competition and whatever they implement just has to be marginally less painful than waiting for your content to download over the cellular network.

1 comment: