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.


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.)

Comments on this page:

The current proposal for integrity verification involves adding hashes to HTML resource references:

The whole point of this hash is to tell the browser to only use the resource if the hash matches. You really think browsers are going to offer a "load it anyway" option when that makes the feature fail at its intended purpose and the feature is being pushed by browser vendors?

By James (trs80) at 2015-06-11 10:13:59:

iOS 9 lets apps specify they only want to use HTTPS, with exceptions listed in a manifest file.

I suspect that, until DNSSEC becomes a "thing" that we use and rely on, this is just an arms race against malicious ISPs. Any ISP that would inject javascript ads would have no qualms about redirecting you to their servers via DNS hijacking, or worse if they could.

I think the best advice is to not give money to companies who do things like this.

Or, you know, use a full-tunnel VPN.

By cks at 2015-06-11 20:27:58:

I feel that DNSSEC is irrelevant here.

Properly working HTTPS is proof against ISP DNS hijacking and renders DNSSEC unimportant. The ISP can hijack your DNS lookups all it wants, but it can't invent valid TLS certificates for the resulting sites. And DNSSEC doesn't help with ISP HTTP interception because modern systems for doing this are quite capable of intercepting and modifying TCP streams on the fly. Sure, you got the right IP address for Google, but if your traffic is passing through the ISP's transparent interception box it is still game over for HTTP.

(An ISP that can invent or obtain valid TLS certificates also runs real risks of detection and extremely bad reactions today. For example, if you intercept Google and someone with Chrome uses your service, their Chrome will scream about it to Google (and not work) and then Google will write a blog post and you will have a lot of adverse publicity and someone probably loses a CA. This risk is only going to get worse for ISPs as more sites and more browsers adopt certificate pinning and certificate problem reporting.)

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, View Normal, Add Comment.
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.