SSL and the future of authenticity 4: Perspectives and Convergence models

Final part of Moxie Marlinspike’s Defcon talk outlines the alternatives of current CA system: ‘Perspectives’ and ‘Convergence’ projects.

‘Perspectives’ model

So, let’s talk about things that I’m a little bit more inspired by. There’s a project called ‘Perspectives’ which came out of Carnegie Mellon University, and it was done by Dan Wendlandt, David G. Andersen and Adrian Perrig. It was originally a paper that was published on using multi-path probing in order to provide authenticity for SSH1 and SSL. And the concept is fundamentally about Perspective.

Basic premise of ‘Perspectives’ model

Basic premise of ‘Perspectives’ model

The basic idea is this: you connect to a secure site, you get back a certificate, and you think “Well, I wonder if the certificate is good or not, how do I validate it?” Well, what you do is you contact an authority, then you say “Hey, what certificate do you see for PayPal.com (in this case)?” The authority makes its own connection to the website, gets its own certificate back, just like a normal web browser would, and then sends that certificate back to you as the client (see image). Now, you compare the thing you got from the authority with the thing you got from this site, and you make sure they’re the same. And so, what you’re essentially doing is you’re using some network Perspective to get a different view on the same site – you know, you have a different network path from wherever the authority is communicating from. We call these authorities ‘Notaries’, and you don’t have to talk to just one Notary, you can talk to any number of Notaries, and they can be distributed around the world so that each has their own unique network path at the same destination. We’re essentially building a constellation of trust.

CA version of Perspective

CA version of Perspective

This idea of using Perspective is actually not new, it’s how SSL works right now. You know, right now, if a site administrator wants to get a certificate for a site, what does the administrator do? They contact an authority and say “Hey, could you please issue a certificate for my site?” And what does the authority do? They send an email to the site with a verification code in it. And if the administrator can receive the verification code and send it back to the authority, the authority issues the certificate (see image). So it’s just using another form of network Perspective to do the same thing, we’re just trying to invert this relationship, so that instead of being site initiated, it’s user initiated.

Now, Perspective – one that was released – came with an implementation, but the implementation was kind of limited. It was initially designed for self-signed certificates, and so it has had some challenges.

Perspectives’ challenges:

– Completeness

– Privacy

– Responsiveness

The first thing challenged is completeness. Since it was initially designed for self-signed certificates, it only works for the initial connection that your web browser sends, so it doesn’t work for any of the background content like images, ESS, JavaScript – all that stuff. So it’s not possible to really eliminate certificate authorities completely using Perspectives.

The second problem is privacy. If every time I make a secret connection to a website I have to make another connection to a Notary, I’m now leaking my entire connection history to the Notary, and that seems a little bit unfortunate.

And the last problem is responsiveness. Perspectives suffer from this idea of ‘Notary lag’. What would happen is you get a certificate, you contact a Notary and you say “Hey, what do you see for PayPal.com?” And the Notary would make a connection to PayPal.com and see the certificate. The problem is that the Notary would cache the response so that it wasn’t constantly having a connection to all of these sites, and then just periodically at some interval pull the site – you know, like once a day or something like that – all the sites that it had certificates for, in order to see whether the site had switched to a different certificate. The problem is that if a site did switch to a different certificate, your responses from the Notary would be invalid for duration of the transaction.

‘Convergence’ model

So, what I’ve done is I’ve taken this concept of using Perspective and I’ve built on it to create a system that I call ‘Convergence’. Convergence is a new protocol, a new client implementation and a new server implementation of this concept. The first thing that we do is trying to address the Perspective’s challenges. We eliminate Notary lag – basically, when you contact a Notary you also send what you saw. So now, the Notary doesn’t have to do any pulling, it just has to contact the server in the case of the cache miss or cache mismatch – so there’s no more Notary lag.

Notary bounce

Notary bounce

The next thing that we did was add privacy. This is two parts: the first part was through local caching, so now whenever you contact a Notary and you say “Hey, what do you think of the certificate?”, if it says “Hey, this is okay” – you go ahead and cache that certificate locally. That way, the next time you connect to the site, you get the same certificate back and all you have to do is check the local cache and see if this thing is good, and you don’t even have to talk to the Notary. So now, you’re only leaking your connection history the first time you visit a secure site, or whenever the secure site’s certificate changes. That still doesn’t seem that great, so the next thing we do is implement Notary bouncing. The idea is that you have a set of Notaries that you have configured as the Notaries that you trust, and you want to talk to all of them. And the first thing that you do is randomly select one of the Notaries and assign it as a bounce. You connect to that Notary, and then you tunnel SSL through the Notary to all the Notaries that you want to talk to (see image). So the bounce Notary is just the dumb proxy shuttling bytes around, and it doesn’t have any visibility into what you’re querying about; the Notaries that you’re talking to know what you’re asking about but they don’t know who you are, and the bounce Notary knows who you are but it doesn’t know what you’re asking about. These SSL connections to the destination Notaries are done using static keys that are configured whenever you add a Notary to begin with, and your browser is just likely a certificate authority now.

Convergence button Convergence is a Firefox add-on, and it looks exactly like the normal Firefox experience, the only difference is that in the upper right-hand corner you get this little Convergence button (see image). If you click this button and enable Convergence, you are completely divorced from the CA system. Everything – foreground content, background content, the certificate authority’s certificates in your web browser – are completely ignored. Everything looks exactly the same, the only difference is that normally when you visit a secure site and you put your mouse over the favicon, you’ll see a little tooltip about who has certified this communication – the only difference with Convergence is we are taking the certificate authorities completely out of the picture, everything else works the same.

The Notary implementation is available for the open source, anybody can run their own Notary, it requires very little resources, and it’s designed to be extensible. The protocol is a REST2 protocol, and the idea is to design a protocol that would support a number of different back-ends. So by default, the default back-end for the Notary is to use network perspective, but you could write any number of other back-ends for the Notary, for instance if you like DNSSEC, the Notary could do DNSSEC to validate the certificate on the back-end, you wouldn’t have to use network perspective. If you’re crazy, you could use CA signatures to validate certificates. You could even use Notaries as front ends to other services, like a Notary front end to the EFF’s ‘SSL Observatory’ which the EFF has volunteered to run. And you configure Notaries that do different things, you can have a set of trusted Notaries, each one does a different thing. And Convergence implementation also has a threshold that you can set on what percentage of the Notaries have to agree in order for them to be sure and meet this consensus. What this means is that with the current CA system you have a certain number of certificate authorities, and if one of them is a bad actor – you’re completely out of luck. And we’re inverting that here, where the more authorities that you have, the more Notaries that you configure – the better off you are, because it means that all of them have to be in cahoots to misbehave or intercept your SSL communication. We have full trust agility, if we don’t like one of these people, we can just remove it, and there are no complications, everything continues to work exactly as it normally would, nothing breaks. And if you like, you could replace it with a different one that does the same thing because you think they’re more trustworthy.

All we have to do is implement Convergence in the four major browsers – and be done.

Other nice things here are that the servers do nothing. You know, people don’t have to make any changes, which means we don’t have to migrate the Internet to anything else. All we have to do is implement Convergence in the four major browsers – and be done. That would be it, that would be the end of the CA system right there. We don’t have to make any changes across the Internet anywhere else. Other nice things are you don’t get any more self-signed certificate warnings; the concept of the self-signed certificate does not exist in the Convergence system. Certificates are certificates – that’s it.

‘Untrusted Connection’ Firefox warning

‘Untrusted Connection’ Firefox warning

There are a few problems. The first is what’s known as the ‘Citibank problem’. Right now, if you’re running Convergence and you visit Citibank.com, you will get a certificate warning – you know, an ‘untrusted certificate’ warning (see image). And the problem is that Citibank apparently has, like, a couple of hundred different SSL certificates, and each one is on a different SSL accelerator, so every time you connect you get a different certificate, which means that all the Notaries see different certificates, your browser sees a different certificate, and it looks identical to the case of being attacked. The good news is that there aren’t many sites like this on the Internet. In fact, Citibank was the only one that I could find, I’m sure that there are others, but they’re pretty rare, so while we might not need to migrate the Internet, we might have to ask a few of these sites to use same practices – like not having hundreds of different SSL certificates.

The other problem right now is captive portals, so if you’re running Convergence right now and you’re like in an airport or in a hotel, you know, you want to connect to the Internet and you get redirected to this captive portal where you have to type in your credit card number before you can actually access the Internet. Now, you want to secure this connection with the captive portal, but the captive portal’s not letting Internet traffic out, so you can’t contact your Notaries. So right now, you have to actually just unclick Convergence in order to deal with this thing, but the good news is that almost always in these captive portal situations we only have to build a Convergence protocol over DNS, and it will work in a captive portal situation.

You can download the software I listed on convergence.io – try it out, it’s a Beta. Look at the server stuff if you want to run a Notary, set one up; talk to people who might trust you and ask them to configure you as a Notary. Even if you’re not going to try Convergence, you’re not into it, the one question that I want to leave you with here today is whenever someone is proposing another authenticity system, I think the question that we should all ask is “Who do we have to trust, and for how long?”. If the answer is “A prescribed set of people, forever” – proceed with caution. In the meantime, try Convergence. Thank you.

Read previous: SSL and the future of authenticity 3: Trust agility concept

1SSH (Secure Shell) is a network protocol for secure data communication, remote shell services or command execution and other secure network services between two networked computers that it connects via a secure channel over an insecure network: a server and a client (running SSH server and SSH client programs, respectively)

2REST (representational state transfer) is an approach for getting information content from a website by reading a designated web page that contains an XML (Extensible Markup Language) file describing and including the desired content.

Like This Article? Let Others Know!
Related Articles:

Leave a comment:

Your email address will not be published. Required fields are marked *

Comment via Facebook: