PRISM and the systems we build

It’s been a strange couple of weeks. On June 5th the Guardian published a secret court order making Verizon hand over the phone records of every customer, every day. The next day the Guardian and the Washington Post published slides about PRISM, which apparently gives the NSA access to data from nine of the big internet companies. And on the 9th the source came forward, Edward Snowden, a 29-year-old Booz Allen contractor working in Hawaii.

The companies all deny giving anyone “direct access” to their servers. The government says it’s all legal and overseen by the FISA court. Both of those can be true and still describe something most people would be pretty alarmed by. The policy fight is going to go on for years and I’ll leave it to people who know more than I do.

I don’t know what PRISM actually is yet, nobody outside does. But I know what I’d find if someone asked me to hand over everything we keep on our users, because I went and looked, and it’s more than I’d like.

The first thing I did on the 7th was run our public endpoints through SSL Labs. We got a B. No forward secrecy anywhere, which means if anyone has been recording our encrypted traffic, and after the last two weeks I’m not going to assume nobody is, then whoever gets hold of our private key later, by court order or by breaking in, can decrypt all of it retroactively. With an ephemeral Diffie-Hellman key exchange (the ECDHE cipher suites) every session gets a fresh key that’s thrown away afterwards, so a stolen private key doesn’t unlock the past. Google turned this on in 2011. It’s a config change if you’re on a recent OpenSSL and an upgrade if you’re not. We were not, so it’s an upgrade.

The second thing I did was look at what we store. Every field on our signup form, every log line with an IP address, every event we keep “because it might be useful for analytics someday”. The honest test I ended up with was: if a court order or an attacker took a copy of this tomorrow, could I explain to the user why we had it? For a depressing amount of it the answer was no. We keep raw request logs forever because nobody ever wrote the job to delete them. We ask for date of birth on signup and I can’t find a single place we use it.

The third thing was our internal traffic. Our database connections and service-to-service calls are plaintext, on the theory that it’s “our network”. Our servers are in someone else’s data center and some of that traffic crosses links we don’t own, so that theory deserves a lot more skepticism than it’s been getting.

There’s a deeper version of all this I’m not going to fix this quarter. Disk encryption protects you against someone stealing a drive, not against a legal order to the company holding the drive. If the provider holds the keys, the provider can be made to use them. The only design where “we can’t hand it over” is literally true is one where the keys live with you, or better with the user, and that costs you things like server-side search. For most of what we do that trade isn’t worth it. For some of it, maybe it is.

So, three things are going into our next planning cycle: forward-secret cipher suites (and HSTS) on every public endpoint, TLS on internal database connections, and a real retention policy with an actual deletion job behind it. None of these are big. We should have done all of them a long time ago, and I suspect most of you reading this should too.*

* Firesheep made the “HTTPS everywhere” argument in 2010. It’s 2013. Come on.