malvasia bianca

At work, we went to Def Con last week; my first time there, an interesting experience. (Also my first time in Las Vegas; unsurprisingly, it’s not my sort of city.) I enjoyed just wandering around the conference, and several of the talks were quite good; my favorite was SSL and the Future of Authenticity, by Moxie Marlinspike.

He started off with a history lesson, talking about the Comodo breakin and about the origins of SSL. (He managed to track down the person who designed the SSL protocol, who hasn’t been active for a decade and a half.)

SSL has worked quite well from a security and integrity point of view, but the whole security trust model is quite threadbare by now: there are 650 organizations worldwide that can sign certificates (and the cost to become such an organization isn’t prohibitive if you’re a criminal enterprise of decent scale); that means that lots and lots of people are in a position to be able to run man-in-the-middle attacks. (Which were a theoretical possibility in 1995, but are quite real these days.) And even if all of those organizations are well-meaning, do you really trust their internal security measures? (He gave an example of one registrar that had their private key accessible for more than a year from a directory on their web site.)

So what do you do if you don’t trust one of those certificate authorities? Right now, your options aren’t great: you can, say, remove Comodo from your browser’s list of trusted certificates, but if you do that, you’ll cut yourself off from all web sites that have a certificate signed by them, which is apparently somewhere around a fifth of all web sites. Or you can imagine replacing the distributed certificate authority power with a more centralized one, e.g. one where each root TLD has signing power over certificates associated to its domain; but lots of people in both the US and China wouldn’t want their government involved in signing certificates, and what about supposedly international TLDs?

And then there’s the whole issue of self-signed certificates: right now, if you just want to secure communication and don’t want to get a browser warning, you have to fork over money to a third party, and the benefit that you get for this is increasingly dubious. (This is a problem that annoys me every single day, because my iPhone can’t remember an exception for a certificate I generated myself.)

The core issue here is that we want “trust agility”. Users should be able to decide whom they trust with certification, and be able to revoke that trust and any time. Right now, sadly, our system has low trust agility: the point is that there are three parties involved, namely the user, the site in question, and the authority certifying the site; currently, the site choses the authority, so removing that choice from the user.

(At this point, he digressed to talk a bit about the ability that DNSSEC provides to put your SSL information in your DNS record: this reduces trust agility still further, by eliminating the possibility of removing an untrusted authority from your trust database.)

The basic idea to solve this that he presented is that of “perspectives”. When you get a certificate from a site that you want to talk to, don’t ask that site for the authority to use to authenticate the certificate. Instead, ask a third party (a “notary”) to also get the certificate from that site: if they get the same certificate that you do, then either you’re dealing with the correct certificate or the man in the middle attack is in between the site and both you and the notary!

This has some flaws: something about not applying to all communications that I didn’t understand, privacy (the notary knows whom you’re talking to), and notary lag (caching problems, basically). So he proposed a tweaked version, namely “convergence”.

Convergence takes this perspectives notion and modifies it in a few ways:

• You send a certificate with the notary request; if the certificate doesn’t match the notary’s cached version, then the notary can check again before sending an inappropriate mismatch response.
• Have the client cache certificates, to improve both performance and privacy.
• Have the client talk to multiple notaries, e.g. allowing you to implement voting behavior and to configure specific notaries for different domains.
• For any communication, proxy the notary request through one of the notaries: that notary doesn’t know which site you want info about, and the notaries that actually receive the request don’t know who asked for the information, preserving privacy.

There are still some problems (Citibank has multiple certs for the same host; captive portals present a chicken-and-egg problem), but they seem workable. And I really like the fact that it removes certificate authorities from the loop entirely, treating self-signed certificates no differently from externally-signed certificates. (And if you wanted I imagine that you could modify the voting behavior to allow externally-signed certs to get an extra vote, or something.)

He’s published source code for a notary server and a Firefox plugin. It definitely seems worth a try, and is a useful reminder that I’m depending more than I’m comfortable with on closed systems: I’d like to run this on my phone, and I can’t. There are reasons why I’ve moved away from open systems over the last few years, but that move still makes me sad, and I’m losing as well as gaining in that trade.