 Okay, so there's a well-known problem for speakers at conferences like these. You know, DEF CON is a big place, people are spread out, people are still coming and going, and you know, at the beginning of your talk, probably there's still people coming in, everyone hasn't really made it yet. And so what speakers do is they try and start slow so that nobody misses any of the interesting stuff. So, you know, they'll start with a tedious bio about their background or go into the, you know, the history of the problem that they're going to be talking about. But I don't really, I don't really like that stuff, so. I want to try something a little different, where I'm just going to tell, for the first three minutes here, a completely unrelated, totally random story that has nothing to do with computer security or this talk. Here it goes, story goes like this. Okay, so just after I'd gotten out of high school, me and some friends had this hairpin scheme, where we thought that we were going to travel to the Caribbean, find an uninhabited island and like colonize it. Yes, I know. I blame the ADSE on my youth. So, you know, this is, you know, a long time ago and back then driving was cheaper than flying. So we drove all the way to Miami before getting on an airplane for a short flight into the Caribbean, where we tried to find a boat, et cetera. It didn't really work out, obviously. We were very hungry. And so then, you know, on the way back, we were driving back up north through Florida, you know, feeling somewhat defeated. And we decided to stop for lunch at some point. And we actually wanted to, you know, stop and get out of the car. So we saw this like kind of Tex-Mex type restaurant, you know, the kind of place with like ships and you sit down, that kind of thing. So, you know, we stopped and we got out of the car and we started walking towards this restaurant. And, you know, through the parking lot, about halfway there, I was with two friends and one of them realized that he'd left something in the car or that he'd left it unlocked or something like that. So he turned around and went back to the car while my other friend and I went into the restaurant. And when we got into the restaurant, we caught the end of their birthday ritual. You know, I feel like these restaurants all have their own sort of unique birthday ritual. They have like a special song or something that they sing when people come out. And so we caught the end of theirs. And it was the strangest thing I've ever seen in a restaurant. So they came out, you know, singing and there's two waiters. And one of them stood in front of the woman whose birthday it was with a little like saucer, you know, plate type, you know, almost like you put a teacup on it or with just a little dab of whipped cream on it and a spoon and held it in front of her and asked her to close her eyes and open her mouth as if he was going to feed her this whipped cream. Meanwhile, there was another waiter standing behind her with a full pie tin full of whipped cream and she closed her eyes and opened her mouth and the dude reaches around. It just slams her in the face with the whipped cream, you know. I mean, this lady's shocked, you know, it's her birthday. She's dressed up. She just gets like a pie to the face, you know, no warning at all. And so my friend and I are standing there like, you know, looking at this, you know, mouths open and my other friend is still at the car. So my friend who's standing there looks at me says, Hey, I think it might be Jack's birthday today. So, you know, we come in and we sit down and I stir up tissuesly during the meal, get up and go and talk to the waiter. I'm like, Hey, you know, it's my friend's birthday today. I don't know if you do anything here. And he's like, Oh yeah, we got a thing we do, you know, we'll come out. And so I was like, great, you know, I go and sit back down. We're waiting. Eventually, you know, they come out, sing in the song and everything. And, you know, our friend is looking a little bit bewildered, you know. And he later confessed that he thought that we had told them that it was his birthday so that we could get like free cake or something like that. So he starts, you know, willingly playing along and they put a little hat on him and then sure enough, they do the thing where they, you know, hold the little dab of whipped cream in front of them and closes his eyes, he opens his mouth and the dude reaches around by him just slams him in the face. And, you know, I knew this was coming. So I had one of those disposable cameras, you know, that used to use it back then, you know, and I had it under the table as all ready. And so I got him right, right at the moment, you know, just the look on his face is just pure shock. All right, anyway, I hope that was more interesting than a three-minute, you know, description of my background. Okay, let's talk about SSL on the Future of Authenticity. Really, this talk is about trust. And I want to start this talk out with another story. It's kind of a downer, but I feel like it's illustrative of the situation that we're in. And the story is about a company called Komodo. They're a certificate authority and according to NetCraft, they certify somewhere between a quarter and a fifth of the certificates on the internet today. So they're the second largest certificate authority in the world. And in March of this year, they were hacked. The attacker was able to make off with a number of certificates, you know, mail.google.com, login.yahoo.com, Skype. Basically everything that the attacker would need to intercept login credentials to all of the popular web mail providers and a few other services. And so immediately after the attack, the founder and CEO of Komodo issued a statement where he said, this attack was extremely sophisticated and critically executed. It was a very well orchestrated clinical attack. And the attacker knew exactly what they needed to do and how fast they had to operate. He went on to add that all of the IP addresses involved in the attack were from Iran. You know what this means. Cyber. But he didn't leave it at any window. He actually spelled it out. He said, all of the above leads us to one conclusion only, that this was likely to be a state-driven attack. So he's painting a pretty complete picture for us here. This isn't just a hack. This is war. And he was to blame Komodo for falling into the full assault of a state-sponsored invasion from a cyber army. And so ironically it was these statements that really catapulted the story out of the trade press and into the mainstream media. And so a number of reporters called me and they all had the same question, what does this mean? What can this attacker do? And I said, well, it means they can intercept communication to these websites. And the reporters would say, well, how? How would they use these certificates to do that? And I would say, well, I think just commercial solutions, like the blue code and a few other scary interception devices out there. And I was talking to one reporter who asked me, she said, no, what is the easiest way? What is the most straightforward way that an attacker would leverage these certificates? And I thought about it and I said, well, the attacker could just use SSLSNF, which is a tool that I wrote to perform man-in-the-mill attacks against SSL connections. Now interestingly enough, when Komodo published their incident report, they also published the IP address of the attacker, which is somewhat unusual. But I think that they were doing this to sort of underscore the Iran, Iran, Iran thing, because this is the IP address is registered to a block in Iran. And so I was thinking about that reporter's question, SSLSNF and all that stuff. And so I thought, well, I wonder. So I went and I looked at my web logs for my web server where I host SSLSNF. And sure enough, the morning after the attack, the same IP address that Komodo had published downloaded SSLSNF from my website. Now there's some other interesting things in here. First of all, the attacker's running Windows. And also interestingly, the attacker's web browser is localized to US English. But the most interesting thing was the referrer. So I went back to my web logs and I found the point that the attacker initially made a connection with my website so that I could see the website that they had visited before. And so the referrer was a hack five video on using SSLSNF. For those of you who don't know, hack five is sort of like a set of video tutorials that are pretty introductory material for people that are just getting interested in this kind of thing. So just to break this down for you, on one hand, we have the CEO Komodo saying this is a clinical attack. And on the other hand, we see that the attacker is literally following video tutorials on the internet. I mean, maybe that was a great video. I don't know. I haven't watched it yet. It could have turned him into a clinical attacker, I'm not sure. And then there were a number of other sort of embarrassing searches that led them to my same website again and again throughout the day. So I caught the Google search referrers, which were things like SSL protocol, a man in the middle, how to IP tables pre-routing. Apparently, he was having some trouble setting up their IP tables. So I was kind of chuckling about this to myself. And then the attacker posted a communique. And it could not have been more embarrassing. I mean, he alternated between making these grandiose and possible claims about how he's hacked RSA and all this stuff, while simultaneously very proudly declaring that he's capable of doing extremely trivial things like he can export functions from DLLs and create his own Silk BPI's and stuff like that. So this could not have been more embarrassing for really anybody involved. The attacker, Komodo. But what was worse is he just wouldn't shut up. He just kept posting communiques. Each one more embarrassing than the last. And I think he posted six in total. He also did interviews with the press, and all the stuff was ridiculous. And so the Komodo CEO and founder responded to these events by making a statement where he said, if this were a secure and trusted DNS, this issue would be a new point, exclamation point. We need a secure and trusted DNS exclamation point. So this guy has just very enthusiastically declared that he does not understand the business that he's in. On one hand, he seems to be suggesting that DNS tampering is the only way to perform a man-in-the-middle attack, which is just not true. And on the other hand, even if that were true, the reason that we have SSL certificates is to stop man-in-the-middle attacks. If man-in-the-middle attacks weren't possible, we wouldn't need the certificates that he's selling us. Later that month, they got hacked two more times. And the next month, they got hacked again. Now, normally, it wouldn't take this much time to be so critical of a company like Komodo. But I think it's an interesting story, because I think there's an interesting question here, which is, what happened to Komodo? After all of this, it couldn't have been more embarrassing, could not have been worse, really. What happened to them? Nothing. Their business didn't suffer. They didn't lose customers. They didn't get sued. Really, the only thing that happened to Komodo this year was the CEO was named entrepreneur of the year, the RSA conference. And so I think that this is the essence of the problem that we're looking at. This is the problem with SSL today. So let's take a moment and just sort of step back and look generally at secure protocols. Any secure protocol needs to provide three things, secrecy, integrity, and authenticity. It has to provide all three. If one of these fails, the whole protocol will fall apart. But we need to remember that SSL, which is a secure protocol and it's trying to meet these objectives, was designed in the early 90s. And things were different there. There wasn't a lot of information available on how to design a secure protocol. Books like Applied Cryptography had not been published yet. If you wanted to use RSA, the algorithm, you had to license the patent from RSA, the company. You had to pay money in order to just even perform this type of cryptography. E-commerce didn't exist. The idea of transmitting your credit card number over the internet was totally foreign. There were no such things as web applications, really. People weren't really transmitting their login and password credentials through websites. And the internet itself was tiny. In 94, according to ISC, there were less than 5 million hosts on the entire internet. Compare that to today, where we're about to run out of public-facing IP addresses at more than 4 billion, or at 4 billion. At the time, there were probably less than 10 secure sites that you could think of. Less than 10 sites that, for some reason, you wanted traffic to be encrypted to these websites. Whereas today, there are more than 2 million certificates on the internet, more than 2 million sites that are using SSL. At the same time, it's worth remembering that SSL was developed at Netscape. And this was an environment of really intense pressure. The race was really on then. And this is the same place where a series of 4AM decisions gave us JavaScript. And we're still dealing with that today. So actually, when you look at it, the designers of SSL were actually pretty heroic. They didn't have a lot to work with. And they were working in circumstances that are totally different than our circumstances today. And yet it served us pretty well. When it comes to these first two things, secrecy and integrity, they did OK. There have been some problems, and there's still some problems. But the piece that has always caused some real fortune is now causing real problems is the authenticity piece. Now, authenticity is important, of course. Because normally, if you establish a secure session with a website, the problem is that if you don't have authenticity, someone could have intercepted your connection to that website. They establish a secure session with you. They make their own secure session with the website and just shuttle data back and forth, logging it in between. But what's easy to forget is that this attack, a man in the middle attack, was entirely theoretical in 94 or 95. The network tools didn't exist. This wasn't the kind of thing that was actively happening. This is thought of as an academic thing. It's like, oh, well, there's this other thing called the man in the middle attack. And we need to design something theoretically to prevent against that. And so the designers came up with a solution that was certificates and certificate authorities, where every site has a certificate. And it's known to be authentic because it's assigned by a certificate authority, which is just some organization that we've decided to trust. So I had this hypothesis that we've outgrown the circumstances in which SSL was originally imagined and that this is a different world today. And then I thought, well, I wonder if that's true. I wonder what they were actually thinking. And so I thought, well, I should talk to the people that designed SSL. And so I did some research and I figured out that SSL was originally designed by this guy, Kip Hickman, who was a Netscape employee back in the day. And the last thing that Kip Hickman posted to the internet was in 1995. So it was difficult to find him. I talked to some people at Netscape who pointed me in the right direction and eventually I tracked him down. And I basically just cold called him. And I talked to him on the phone and he was a great guy. And he was like, oh, SSL. Yeah, I hadn't thought about that in a long time. Wow, OK. And he's like, oh, yeah. And I was like, certificate authorities, what's the deal? He's like, oh, that whole authenticity thing. He's like, yeah, we just threw that in at the end. He's like, SSL, we were designing it to prevent passive attacks for the most part. We heard about this thing, the man in the middle attack. And so we just threw that in at the end. He's like, really, that whole thing with certificates, it was a bit of a hand wave. It's like, we didn't think it was going to work. We didn't know. And the idea back then you could say made sense, right? If you look at the number of domain names on the internet back in 94, where that number of the graph is approaching zero, it makes sense that, OK, maybe you have 10 sites that you could identify as secure sites. And so you have one organization that just looks at those 10 sites really carefully and makes a decision and signs those certificates. But if you try and scale that up over time to today when there's almost a billion domain names on the internet, and ideally we'd like all of them to be secure, it seems a little bit unrealistic to think, well, we're going to have an organization or even a set of organizations that's going to look appropriately, closely at all of these domain names. When I asked Kip about how he saw the scaling over time, he was like, oh, scaling, we didn't really think about it. He was like, you've got to remember, at the time when this was designed, Yahoo was a web page with 30 links on it. He's like, that's what Yahoo was. OK, yeah, that's different. And history has really borne this out. Ivan Ristik put together a nice little threat matrix of all of the possible problems with SSL that have cropped up in the past. And up over here in this corner, you see some of the problems with secrecy and integrity that have come up. But it's managed to sort of squeak by. And down here, there's some of the problems with user interaction. These are things like SSL strip. But in terms of the protocol itself, this stuff up here with the authenticity piece has been where all the real problems are. And I think looking back at the Komodo thing, the lesson from these events shouldn't be that this was cyber war, because I think pretty clearly it wasn't. But that this is happening every day. That's the real story. One of these domains the attacker got, logging.live.com, we should remember that Mike Zussman got this just by asking for it. He didn't have to export functions from DLLs or create his own soap APIs or whatever. He just sent in a request. Eddie Nigg got Mozilla.com with no validation at all, just asked for it. Verisign issued a code signing certificate for Microsoft Corporation to attackers that are still unidentified. They were never discovered. I mean, this kind of thing happens all the time. Just recently, I needed to get an SSL certificate. So I went to this website, sslinabox.com, straight to the bottom of the barrel. And it's one of these things where you have to create an account in order to submit anything. So I go to create the account. And when I click Create, it just logged me into someone else's account. It's like the one that was broken. And I was like, well, fuck. I'm not even trying to hack this. I just want a certificate. So I logged out and I tried to create an account and logged me into someone else's account. And every time I did it, I just got a different account. And the thing is, it's like I didn't even bother emailing them about it because I'm sure that they don't even care. There's this certificate authority that published the key to their certificate in the public directory of their web server. This is a certificate authority. And the thing is, you could kind of understand. I mean, not really, but you might be able to understand how it's possible that someone could have made this mistake. But it's still there. It's not like they were like, oh, crap. And removed it. Since 2009, the key to their certificate has been available for the public. StarCom recently got hacked. We don't really know what happened. You don't even have to hack anybody. If you've got the money, you can just buy a certificate authority. You can get a CA cert from GeoTrust. I think it's 50 grand. Anybody has 50 grand to spend? You get your own CA cert, intercept all the communication on the internet. I really like their iconography in the top right corner because it really is. It's just like, we're giving you the key to the world. They're not high in anything. And what if this were a state sponsored attack, this whole Komodo thing? I think it's worth realizing that the only reason that Iran would have to hack a certificate authority in order to issue certificates is because they don't have a certificate authority of their own. But many other countries do. The EFF put together an excellent project called the SSL Observatory, where they scan the internet. And they put together a map of all the countries in the world that are currently capable of issuing certificates and thus intercepting secure communication. And it looks like this. I mean, I don't know if you can see, but way out in the middle of the Atlantic there is a little red speck. That's Bermuda. Bermuda can issue certificates. So I think the good news is that the vibe around the sort of thing seems to be shifting. From the old vibe of total ripoff, which I think was the general perception of certificate authorities, to the new vibe of total ripoff, and mostly worthless. But so there's been a lot of talk about moving forward and replacing certificate authorities with something else. But I think that if we're going to do that, it makes sense to really accurately identify the problem and figure out what it is that we're trying to solve so that we don't end up in the same situation again. Now, there have been, I think, a few sort of general perceptions of what the problem might be. The first is people look at the EFF SSL Observatory data. So the EFF scanned the internet and they put together a graph of all of the organizations in the world that are currently capable of signing certificates. And it's a lot of organizations. In fact, it's 650 different organizations are currently capable of intercepting communication. And so I think one simplistic reaction to this is just to say, well, the problem is that there's too many certificate authorities. There's just too many of them. What we need is fewer certificate authorities. But I feel like this might be a little simplistic. For instance, remember when there was only one and they could charge as much and do really whatever they wanted. And part of the problem here is really a scaling issue where we've gone from maybe 20 secure sites to 2 million secure sites. And ideally, we'd like a billion secure sites. It seems like less is not really the answer. If anything, we would want more organizations that are capable of being on the ball here. Another kind of general perception is that there's just a few bad apples, that most of the certificate authorities are cool and there's just a few certificate authorities that have given the whole thing a bad rap for everybody else. But I also don't know if this is true. I think that if you look closely, there's really nobody here that does not have dirt on their hands. Even Verisign, back when they were the only game in town, at the same time that they had a business issuing certificates and securing communication, had another section of their business where they were managing so called lawful intercept services for governments. So the same organization that we had entrusted to secure our communication was also simultaneously making money by intercepting secure communication. And I think if you look closely, there's really nobody here that isn't similarly distressed. Another idea is that it's a scoping issue. That the problem is that the authorities are all on the same scale. So for instance today, two authorities who can sign certificates and thus intercept secure communication on the internet are the Department of Homeland Security and the state of China. And so this idea, well the problem is that the DHS can sign Chinese sites and China can sign US sites. And really, if we just separated the scope and China could only sign sites in China and the Department of Homeland Security could only sign sites in the United States, everything would be cool. And while this might be an improvement, I feel like it's kind of a low bar. I think there are plenty of people in China that probably don't trust the state of China to certify sites even within their country. And likewise I feel like there are plenty of people in the United States who don't trust the Department of Homeland Security to be certifying their communication either. So in order to answer this question, what is the problem? I think it's a good idea to look back at the first question, what happened to Komodo? Well nothing happened to Komodo. But why? Why did nothing happen? What could we have done? If I decide that I don't trust Komodo and I don't, the very best thing that I can do is remove them from the trust database in my web browser. I could say, OK, they are no longer a trusted authority. The problem is that if I do that, somewhere between a quarter and a fifth of the internet just disappears. Totally breaks. I can't visit those sites anymore. And sure, I could take an ideological stance to never visit those sites again because they're mixed up in the Komodo cabal of whatever. But really there's no appropriate response. And the thing to remember is that this is as true for browser vendors as it is for you or me. Browser vendor cannot remove Komodo from their trust database because they're just going to be breaking somewhere between a quarter and a fifth of the internet for all of their users. They're in the exact same situation that you and I are. The truth is that somewhere along the line we made a decision to trust Komodo. And now we are locked into trusting them forever. And I think that this is the essence of what we're looking at today, that we can boil down all the problems that we've had with certificate authorities to a single missing property. And I call this property trust agility. The idea is that trust agility provides two things. One, that a trust decision can be easily revised at any time. There are plenty of people that say, oh, Moxie, don't trust anybody. But that's not true. I mean there are plenty of organizations that I could identify today that I trust to secure my communication, for me. But what seems insane is to think that I could identify an organization or set of organizations that I would be willing to trust not just now, but forever, regardless of whether they continue to warrant my trust and without any incentive to continue behaving in a trustworthy way. The second property of trust agility is that individual users can decide where to anchor their trust. And this could be the same thing as saying individual browsers can decide where to anchor their trust. And I think this is important. Right now there's this idea, oh, there's this scoping problem, that VeriSign and Commodore are in the same scope. And that, well, if we just separated the scopes, then if VeriSign did something particularly egregious, a site like Facebook could switch to a different certificate authority, and this would actually have some significance because VeriSign would be unable to continue signing certificates for Facebook, which is currently not the case. But I think if it's been a struggle to get websites to deploy HTTPS or SSL to begin with, it seems a little bit far-fetched to think that they're going to continue making really active decisions in our best interests. And what's worse in this increasingly globalized world, it doesn't seem like it's really possible to make one trust decision for everybody, that different people live in different contexts with different threats and have different needs and probably trust different individuals. And so what's more, it's our data. It's our data that's at risk here, not the site administrator, not the company that's operating this web service. It's the user's data, and I feel like it should be the users or the browsers who get to decide who to trust. This property that individual users decide where they can anchor their trust is really just a simple but powerful inversion of the way that things already work. Currently, there's three entities involved in any one of these transactions. There's the client, the server, and the authority, and that this trust relationship is initiated by the server. The server talks to an authority and says, hey, please certify me. The authority responds with a certificate that is eventually given back to the user through the site. And what we're talking about here is just doing a simple inversion where it's the user or the client that initiates this trust transaction and talks to the authority, the authority, and says, please certify the site for me. The authority certifies that site and responds back to the user. The reason this is so powerful is because now this means the user can decide what authority they need to talk to, which means that this issue of scoping is not such a big deal. The fact that the Department of Homeland Security can sign sites in China is not an issue because users in China will just ignore it and talk to some Chinese authority. Or they might decide they don't trust China either, and they talk to some NGO or something else instead. I think that these two components of trust agility are really powerful, and I think that they are exactly what's missing from the CA system today. And that is where all our problems have come from. So I want to take a few minutes to talk about DNSSEC because there's been a little bit of talk recently about using DNSSEC to replace the authenticity piece of SSL. And the basic idea is this. You take your SSL certificate on your site, and you shove it in your DNS record. That's basically the gist of it. So you have a cert. You put in your DNS record. That way, when a client goes to contact a site, it does a DNS lookup, it gets back a DNS response with not only the IP address, but also the server certificate embedded in the DNS response. That way, when they connect to the server, they just make sure that the certificate they see is the same thing they got in the DNS response. And this thing is known to be authentic because it's signed because we're using DNSSEC. Now, this scheme has a really immediately visceral appeal, and I think it's because people tend to mentally associate DNS with the word distributed. And distributed sounds really good right now. It sounds like exactly what we need. After suffering under the centralized yoke of certificate authorities for all these years, it would feel good to just wipe them off the page and replace them with a distributed system instead. But when you start to look closely at it, the way that DNSSEC works is that it's the information that is distributed. The information in the DNS records is distributed across the various zones on the internet. But the trust is incredibly centralized and hierarchical. And this is actually exactly how the CA system works today. The information, the certificates, are distributed across the web servers of the sites that are serving them on the internet, and the trust is highly centralized in this hierarchy of certificate authorities. So the next question is, well, OK, if it's still centralized trust, maybe there's something about the people that we have to trust, or maybe there's some increased trust agility here that would be appealing. So let's look at the trust requirements. There are three main classes of people that you have to trust under DNSSEC. The first is the registrars. I feel like if CAs are sketchy, they're taking it up a notch. Personally, I think it should be laughable that the current first step in deploying DNSSEC is to create an account with GoDaddy. I think that should be laughable. The second class of people that we have to trust here are the TLDs. So these are the companies that manage the top level domains. So in the case of .com and .net, the largest TLDs on the internet, the company that manages those is Verisign. Same player, same game. If you look at other TLDs like .org and .edu, the companies that manage them are probably not companies that you've ever heard of. I would at least suggest that if you were to think, oh, who's like a really trustworthy company, who's really has a strong sense of integrity, these companies are probably not the first that would come to mind. Take a minute to look at the organizations that manage the other TLDs and look at the executive boards, look at people managing the operations, and ask yourselves, are these the people that I want to trust with all of my secure communication in the future? There's also the country co-top level domains. So does everyone that's using TLDs that are kind of hip, like .io, .cc, and .ly, trust the corresponding governments for these countries to secure all of their communication? What about TLDs like .ir and .cn? Should the citizens of these countries have to trust their governments with all of their secure communication to local sites? This is the current picture of what countries around the world are capable of intercepting secure communication based on the EFF SSL observatory data. This is what that picture would look like under DNSA. And if the recent domain seizures are any indication of the future, it seems like these TLDs could be dangerous. And then the third class of people that we have to trust here is the root. And that's ICANN. Now, I don't have any particular beef with ICANN, but while ICANN has made a great effort to be a sort of global organization, as far as I know, and I could be wrong, but as far as I know, fundamentally they are just a California 501C3 nonprofit, which as far as I know means that they have to abide by laws in the United States. And if this legislation that's been coming up recently, like COICA and protect IP and this kind of thing, to me, the real lesson here isn't whether this passes or not, because there's been some kind of heroic efforts to prevent this legislation from going through. But I think the thing to take away from this is that they're trying to pass legislation that messes with this stuff. And maybe one day it'll succeed. And I think ICANN would be subject to that regulation in that case. The worst part about all of these organizations is that this system actually provides reduced trust agility. That today, even as unrealistic as it might be, I could still choose to remove VeriSign from my list of trusted certificate authorities. But there is nothing that I can do to stop VeriSign from being the company that manages the .com and .net TLBs. So if we sign up to trust these people, we're signing up not to trust them just now, but forever. Regardless of whether they should continue to warn or trust, with no ability to change our mind about whether we should continue trusting them without any incentives to continue behaving appropriately. 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 Winlint, David Anderson, and Adrian Perrig. And it was originally a paper that was published on using multi-path probing in order to provide authenticity for SSH and SSL. And the concept is fundamentally about perspective. The basic idea is this. You connect to a secure site, you get back a certificate. And you think, wow, 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. Now, you compare the thing you got from the authority with the thing you got from the site. And you make sure that 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, that you have a different network path from wherever the authority is communicating from. And 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 have their own unique network path to the same destination. You're essentially building a constellation of trust. This idea of using perspective is actually not new. It's how SSL works right now. Right now, if a site administrator wants to get a certificate for its site, what does the administrator do? They contact an authority. And they 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. So it's just using another form of network perspective to do the same thing. We're just trying to invert this relationship. So instead of being site-initiated, it's user-initiated. Now, perspectives, when it was released, came with an implementation. But the implementation was kind of limited. It was initially designed for self-sign certificates. And so it has had some challenges. The first big challenge is completeness. Since it was initially designed for self-sign certificates, it only works for the initial connection on the your web browser sense. So it doesn't work for any of the background content, the images, CSS, JavaScript, all that stuff. So it's not possible to really eliminate certificate authorities completely using perspectives. The second problem was 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 was responsiveness. Perspectives suffered 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 a certificate. The problem is the notary would cache the response so that it wasn't constantly having to connect out to all of these sites. And then just periodically at some interval, pull the site, 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 the duration of the poll interval. 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 try and address the prospective challenges. We eliminate notary lag by basically when you contact the notary, you also send what you saw. So now the notary doesn't have to do any polling. It just has to contact the server in the case of the cache miss or cache mismatch. There's no more notary lag. The next thing that we did was add privacy. So 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 AOK, you go ahead and cache that certificate locally. That way the next time you connect to the site, you get the same certificate back. All you have to do is check the local cache and say, yeah, this thing is good, and you don't even have to talk to a 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. But so 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 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. And you connect to that notary, and then you tunnel SSL through the notary to all of the notaries that you want to talk to. So the bounce notary is just a dumb proxy shoveling bites 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 who you're asking about. These SSL connections to the destination notaries are done using static, pre-shared keys that are configured whenever you add the notary to begin with in your browser, just like with certificate authorities now. Convergence is a Firefox add-on, and it looks exactly like the normal Firefox experience. The only difference is in the upper right-hand corner, you get this little Convergence button. If you click this button and enable Convergence, you are completely divorced from the CA system. Everything, foreground content, background content, the certificate authorities, certificates in your web browser are completely ignored. Everything looks exactly the same. The only difference is that normally if 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 free open source. Anybody can run their own notary. It requires very little resources, and it's designed to be extensible. The protocol is a REST protocol, and the idea is to design a protocol that supported a number of different backends. So by default, the default backend for the notary is to use network perspective. But you could write any number of other backends for the notary. For instance, if you like DNSSEC, the notary could do DNSSEC to validate the certificate on the back end. It wouldn't have to use network perspective. If you're crazy, it could use CA signatures to validate certificates. You could even use notaries as fraud ends to other services, like a notary front end to the EFF's SSL Observatory, which the EFF has volunteered to run. And you can configure notaries that do different things. You could have a set of trusted notaries. Each one does a different thing. And the Convergence implementation also has a threshold that you can set on what percentage of the notaries have to agree in order for things to be secure. I think the default is consensus. What this means is that in the current CA system, you have some 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 and intercept your SSL communication. And we have full trust agility. If we decide we don't like one of these people, we can just remove it. And there are no implications. 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 that they're more trustworthy. Other nice things here are that the servers do nothing. People's web servers, you 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, you don't get any more self-signed certificate warnings. The concept of a self-signed certificate does not exist in the Convergence system. Certificates are certificates. That's it. There are a few problems. The first is the Citibank problem, what's known as the Citibank problem. Right now, if you're running Convergence and you visit Citibank.com, you will get an untrusted certificate warning. And the problem is that Citibank apparently has 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 of 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 is the only one that I could find. I'm sure that there are others. But they're pretty rare. And 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 in an airport and a hotel, you want to connect to the internet and you'll 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 is not letting internet traffic out, so you can't contact your notaries. And 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, they let DNS out, which means that we only have to treat. We have to build a Convergence protocol over DNS, and it'll work in a captive portal situation as well. You can download the software I released yesterday from Convergence.io and try it out. It's in 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 or you're not into it, the one question that I want to lead 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.