HTTP should be dropped even as a pure Internet transport mechanism

June 11, 2015

In a comment on my pragmatic view on switching to HTTPS, Aristotle Pagaltzis wrote in part (in two bits I'm replying to separately):

HTTPS basically disables caching. And caching obscures traffic flow by terminating it locally, dispersing and diffusing it.

Plain HTTP caching today has two essentially fatal limits for most people, which is that your 'last mile' ISP can both snoop your traffic and alter it to do things like insert malicious content. Yes, I consider 'ride along' JavaScript ads to be malicious content. The reality is that on today's Internet, your ISP is a threat.

(Your last mile ISP may be doing this on its own behalf, it may be doing it under orders from someone, or it may have had its network quietly altered to do this.)

Since all of these are happening today, it is my view that plain HTTP caching is not worth keeping. It is possible to use it for good, but in practice it and the closely related issue of forced HTTP proxying are too often either used for evil or exploited for evil.

Then:

Now you must reveal to someone that you are interested in certain public content. But if you can verify the integrity of that content you could have a choice of intermediaries to fetch it from, depending on whom you want to reveal your interest to, and whom you want to conceal it from. And no one stops you from using TLS to them in order to shut out intrepid eavesdroppers, of course.

This is clearly a new protocol that carries integrity information along with it and simply uses HTTP as a transport. It's my view that you must use TLS even with this, for what are ultimately pragmatic reasons. If the transport protocol uses unencrypted links such as HTTP, there are two issues.

First, the transport protocol leaks information about what you're reading to your 'last mile' ISP (and possibly others). We already know that ISPs will monitor and exploit this information if it is available. It doesn't matter if you obscure information about where you fetch the resource from; the mere fact that you are receiving web pages about specific subject matter is a deadly giveaway. Expect this information about your browsing habits and your interests to be sold to the usual suspects.

Second, let's consider the user experience of what happens if the ISP takes advantage of this plain text transfer to actually inject its own content. Of course the resource your web browser has fetched fails integrity checks, so it should not show it to you, right? Well, this is the XHTML problem, or perhaps the HTTPS certificate alert problem. The content is there (as the user sees it) except that the browser is not showing it to the user for essentially arbitrary reasons. In my jaundiced view this is not a stable situation and not one that users are going to enjoy. All it needs is one browser to defect to allowing 'show me the content anyway' and then all ISPs are helpfully telling their users to use that option, honest.

Of course an ISP could try to MITM your HTTPS traffic. But we've seen how that show plays out and it doesn't go well for the people doing the interception, primarily but not entirely for social reasons. Without the ability to see and alter cleartext, your ISP is essentially helpless to make alterations; blindly altering the encrypted stream generally creates totally garbled and corrupt results (even ignoring the integrity checks, which will fail).

So my view is that HTTP cannot be used as a transport across the open Internet for anything. At a minimum it can't be used for anything that will wind up in a user browser, and I feel that even with strong integrity checks it leaks too much information to your ISP. Put a fork in it, it's done.

(There are plenty of legacy transport uses of HTTP across the open Internet, of course, so in practice it's not going away any time soon as far as tools are concerned. Browsers are another matter.)

Written on 11 June 2015.
« My pragmatic view on switching to HTTPS and TLS everywhere
Red Hat are marketing email spammers now (in the traditional way) »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Jun 11 00:15:40 2015
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.