It's been fun http:, but a man's gotta move on and there's no place for you on the back of my bike anymore. You were fun once but you're a drag now, and I just can't trust you anymore. It's not your fault but that's the way it is. Sorry, kid. Hey, https:! C'mon over here!

Greetings. Sometimes you just have to bite the bullet when it comes to significant technological changes, and I believe that such a time has come for the basic http: unencrypted Web protocol.

When we first started discussing Network Neutrality some years ago, we mostly talked in terms of trying to make sure that data streams would be handled in a fair and nondiscriminatory manner. Then with the Comcast BitTorrent case, it became clearer that it was appropriate to worry about whether underlying protocols might be manipulated by ISPs, resulting in delays or outright blocking.

But now it's increasingly obvious that we're dealing with a triple-whammy, with ISPs apparently gearing up to treat our data like a 1960s draft board physical. That is (to quote Arlo Guthrie's Alice's Restaurant): "... injected, inspected, detected, infected, neglected and selected."

More specifically, as noted in Google Hijacked -- Major ISP to Intercept and Modify Web Pages and ISPs Spying On and Modifying Web Traffic, ISPs are increasingly taking the stance that our data is subject to ISP-based manipulation of all sorts.

We're not talking about just traffic shaping -- though that's problematic enough in many cases. We're now looking at outright alteration of traffic contents -- the very payload of our Internet communications.

ISPs have argued that such techniques allow for transparent removal of viruses, pop-ups, and so on. But now, feeling empowered by the capabilities of new TCP/IP mangling machines, the situation seems poised for consumers and businesses -- except perhaps those able to pay significant premiums -- to be relegated to serf (no pun intended) status in the ISP kingdoms.

While public policy and legislative changes may eventually address some of these issues, there's something that we can do right now to start assuring that we can control our own Internet communications.

That first, key action is to begin phasing out, as rapidly as possible and in as many application contexts as practicable, the use of unencrypted http: Web communications, and move rapidly to the routine use of TLS/https: whenever possible.

This is of course but an initial step in a rather long path toward pervasive Internet encryption, but it would be an immensely important one.

TLS is not a total panacea by any means. In the absence of prearranged user security certificates, TLS is still vulnerable to man-in-the-middle attacks, but any entity attempting to exploit that approach would likely find themselves in significant legal difficulty in short order.

Also, while TLS/https: would normally deprive ISPs -- or other intermediaries along the communications path -- of the ability to observe or modify data traffic contents, various transactional information, such as which Web sites subscribers were visiting (or at least which IP addresses), would still be available to ISPs (in the absence of encrypted proxy systems).

Another potential issue is the additional computational cost associated with setting up and maintaining TLS communication paths, which could become significant for busy server sites. However, thanks to system speed improvements and a choice of encryption algorithms, the additional overhead, while not trivial, is likely to at least be manageable.

The associated security and privacy benefits make this transition essentially a no-brainer from a cost/benefit standpoint -- at least if we're really concerned about maintaining the integrity of the carefully crafted Web experience that we present to users.

We've gotten a good run from http:, but all good things come to an end. A graceful retirement for virtually all unencrypted Web communications, and a brisk move to routine TLS/https: use, are both honorable and justified -- and practical now.

Let's ride.

--Lauren--

Technical Addendum:

Some early feedback to this posting took me to task for using the term "SSL" rather than "TLS" in conjunction with my call for encryption. OK, ya' got me, TLS is the correct term these days for current systems. I admit it, I'm sometimes guilty of referring to both protocols as SSL in my non-technical, general Internet audience writings.

Among the Internet user population at large the term SSL is still more recognized, from a functional standpoint both SSL and TLS are extremely similar, and they both are intertwined historically. However, I'm properly chastised, have changed the occurrences of SSL to TLS above in the main posting, and will avoid this lapse in the future.

Secondly, it's been noted that a significant holdup to https: implementations in some key environments has been the traditional requirement for a separate IP address when using SSL/TLS, rendering server virtual hosts unusable.

However, RFCs 2817, and 4366 (superseding RFC 3546) address this issue via suitable extensions, and various relevant implementations already exist, though there's more work to do.

I didn't say that a transition to a fully encrypted Web environment could happen overnight. But all of the basic foundational pieces that we need to do so -- with suitable effort -- are already pretty much in place.

--LW--