Heroes in the Fight for Browser Privacy
The fight for privacy in the browser is not over yet, but there are some heroes to be named. Namely, the authors of https://tools.ietf.org/html/rfc7469. The world will never know who they are, nor care, but I assume they are browser security engineers working for Google. I have exchanged a few emails with C PALMER from Chrome-Dev-Sec.
What they have done will protect millions and millions of people from traffic interception. In some countries, from personal persecution, which is the part that keeps me awake at night. That some messed up government (see my last post for which one) will just use public CA, terminate every SSL, and do what they need to do with data.
My belief is that the world doesn’t need better ways for law enforcement to intercept all the traffic in the world and build big data around you. What we need is better authentication to tell the good guys from the bad and then hack only the bad guys on a valid legal basis.
But if we can do that we can focus the resources on the bad guys. And not monitor everyone with fake attention but a few guys with a lot of attention.
A couple of comments about the method:
First, I think it’s great, something is finally well done from the RFC perspective, probably one of the best intros into an RFC I have ever seen.
How it works in a nutshell:
You generate two keys. One is current, one is future. If you lose or compromise both, it’s “bye-bye Common Name.” On the first connection, the browser remembers (pins) both and expects at least one of them. I think you can pin more than two, but I am not sure.
You can pin keys at different levels of validation which makes the whole thing awesome. But here is the best part! If there is a mismatch, there is finally a hard fail and a reporting mechanism which will feed my analytics.
For the first time in browser history, we have something that can actually work.
Since these guys are acutely aware that some good amount of people will fuck it up and lose or compromise the keys they are not recommending it.
So I am going to do a good job at managing it, as opposed to a terrible one. Yes, I just secured my HTTPS connection to the mobile server.
I like it. Mainly because it’s tied to a key and not a cert. So if you are using short-lived certs you can do this, and we can all exhale in a world that looks and feels a lot better.
Unfortunately, it’s is still possible to perform a man-in-the-middle attack if you are there from the start. In my particular instance, it does not matter. Because we have other ways to verify the first connection. I can see how one could redirect traffic to a different phone / hostname upon enrollment but it doesn’t since there is a user verification on the phone. I don’t see a way to get any data of the connection in my use case.
This is a method that I will personally invest a significant amount of time in by providing an open source key management library.
These guys are very cautious about this method because you can easily lock yourself out of the domain. But yes, powerful tools have powerful consequences.
Zeev Glozman is the founder and CEO of Beame.io, an information security company enabling secure connections between mobile devices.
