Counter-Surveillance

Surveillance on the Internet is pervasive and well-funded; it constitutes a planetary-scale attack on people who need the Net. The IETF is grappling with the problem but the right path forward isn’t clear.

This story is being reported, but (near as I can tell) not by anyone who’s on the actual mailing lists, reading what’s being said. So, here’s what’s up. The story is long and unsimple, and therefore so is this ongoing fragment; sorry.

On a perfect Internet · Everyone would be confident that their traffic is private; only they and whoever they’re connecting to could ever see it. They wouldn’t have to worry about what needs to be private and what doesn’t because everything would be.

Then, in civilized parts of the world, if a law-enforcement professional wanted access to someone’s personal information, they would follow a standardized legal process to get it. (The nature of such processes is a matter for discussion in the arena of politics not engineering.)

It’s going to be hard to get there. The Internet is really big, some of the technical infrastructure is old and inflexible, and a quite a few of the people who use it and administer it aren’t prepared to do much (if any) extra work for the sake of privacy. Also, not everyone agrees on what that perfect world is like. Also, the attackers are smart and well-funded.

On the other hand, pervasive surveillance — “Let’s vacuum up all of everyone’s traffic because we might use it later” — is only really cost-effective when accessing the data is free, or at least really cheap. So, anything we can do to drive up the cost of surveillance will improve privacy and safety for the citizens of the Net. So, let’s do those things, and not let our ongoing work towards a more perfect solution get in the way.

Raw data · Let’s start with the statement of principle, a work-in-progress by Stephen Farrell: Pervasive Monitoring is an Attack.

The IETF discussion is taking place mostly on two mailing lists: HTTP Working Group and Perpass, where the volume, intensity, emotion, and complexity all run high. I’ve been sacrificing some slices of my personal life notably including sleep in an effort to keep up.

Individuals have attempted to bring some order to the discussion; one such effort is Paul Hoffman’s Encryption Terminology. Another is my own Pervasive Privacy Pros and Cons.

Goalposts · In the near/medium-term, there are two things the IETF could do to frustrate the attackers. Both focus on the Web’s HTTP protocol, because that’s where most of the interesting traffic is. There’s other work on SMTP and XMPP and SIP and so on, but let’s stay with HTTP.

At the moment, when you hit a Web address that begins with “http:”, it’s fairly straightforward for an attacker to fool you into connecting with the wrong server, and also to intercept and read the data going back and forth. We call this “plaintext mode”.

But when it begins with “https:”, your connection should be authenticated — you can be sure that the server in the address bar is who you’re really connected to — and encrypted — prohibitively expensive, in effect impossible, for someone capturing the data to decode it. [Important note: “https:” connections can be spoofed and spied on if implemented incorrectly, or the attacker has stolen the server’s secret keys, or has planted malware on your PC/mobile.]

The first thing the IETF could do is “opportunistic encryption”: This arranges that sometimes, when you connect to an “http:” address, you’d get encryption (probably not authentication) without asking for it, or maybe even knowing.

The second has to do with what’s being called “HTTP/2.0”. For many years, the Web has been running largely on HTTP/1.1. Recently, there has been intense work on HTTP/2.0 by people at Google and the other browser builders; an interim version called SPDY is already in production, at Google among other places. Privacy advocates are proposing that HTTP/2.0 not be available in plaintext mode; authentication and encryption would be required. The idea is that since HTTP/2.0 has many advantages, including being faster, this will drive adoption of good privacy practices even by those who don’t particularly care.

The controversy · The IETF is full of loudmouths, and it is very rare that any new thing, or improvement to an existing thing, sails through without bitter argument. This is as it should be; the Internet has become critically important to human civilization and we should make changes only with extreme caution.

But even by IETF standards, the pervasive-surveillance-pushback debate has been unusually fierce and voluminous.

There are a surprising number of people who, for a surprising number of different reasons, are generally not on board with either of the short-term strategies the IETF is looking at.

It’s not so much that it’s reasonable to be suspicious of people’s motives, it’s that in this scenario, it’s silly not to be. In particular, those who are arguing against privacy measures are subject to a very specific suspicion: That they are on the attackers’ side, either for reasons of principle or because they want to sell surveillance technology. And in fact employees of both the spooks and the surveillance-tech vendors are active in the IETF.

The factions · Suspicion aside, and bearing in mind that in the IETF people are supposed to speak for themselves not on behalf of organizations, and also that opinions are highly fragmented, there are some roughly-identifiable opinion clusters, not organized or anything; but describing them may help people understand what’s going on.

The Privacy Partisans are aggressive about doing whatever’s possible by way of counter-attack, and doing it now. This notably includes engineers from Firefox and Chrome, who say that for HTTP/2.0, they’re just gonna run authenticated and encrypted all the time, whatever anyone says.

The Cynics are unconvinced about the usefulness of the counterattack measures on the table. They think that the technology isn’t good enough, or the secret-key infrastructure is corrupt, or that Google and Facebook and so on should be seen as attackers, or developers are just too lazy and incompetent to get the deployment right.

The Enterpriseys are people who think that surveillance is necessary because there are situations where law or policy require it. Examples include prisons, businesses that want to control their employees’ Net access, and devops folks who want to monitor for malware or do load-balancing.

The Unconvinced just don’t see the need for aggressive privacy protection; they think it’s foolish to apply it to public static brochure-ware, or that it’s unethical to impose encryption on people without asking them, or that it’s insane to try to encrypt the Internet of Things: Printers and toasters and so on.

Disclosure: I’m a privacy partisan. I think the current technology, while imperfect, is good enough to be useful; I don’t want to live on an Internet optimized for prisons and printers; I think it’s perfectly possible to comply with the law and still protect people’s privacy; and I think everything should be private because otherwise things that are private are suspicious. But I understand that there are smart people who disagree, and I respect some (not all) of the people and some (not all) of the arguments.

What’s next? · Beats me. I’m encouraged by the fact that a lot of browser engineers are pretty determined to push the privacy rock up the hill. Even more important, I think I sniff a change in the popular mood, where not every abusive intrusion into ordinary people’s lives can be justified by robotically chanting “9/11”.

But doing privacy right is really, really hard. It would be unsurprising if this effort gets derailed, either by politics or engineering issues. It would be disappointing if the community let a derailment or two put out the fire. I think it may take years of hard work to make any significant improvement. I have zero doubt that the work is worth doing.

If you care about this stuff, and you’re competent with these engineering issues, you really might want to consider joining a couple of these mailing lists or, even better, pitching in on open-source infrastructure.

---

---

Contributions