Moxie Marlinspike >> Blog >> SSL And the Future Of Authenticity

The Background

In the early 90’s, at the dawn of the World Wide Web, some engineers at Netscape developed a protocol for making secure HTTP requests, and what they came up with was called SSL. Given the relatively scarce body of knowledge concerning secure protocols at the time, as well the intense pressure everyone at Netscape was working under, their efforts can only be seen as incredibly heroic. It’s amazing that SSL has endured for as long as it has, in contrast to a number of other protocols from the same vintage. We’ve definitely learned a lot since then, though, but the thing about protocols and APIs is that there’s very little going back.

Generally speaking, all secure protocols need to provide three things: secrecy, integrity, and authenticity. If any of these break, the whole protocol breaks. SSL doesn’t do any of the three very elegantly by today’s standards (and in many cases just barely squeaks by), but most of the practical attacks we’ve seen over the past ten years have focused on the authenticity piece. The designers of SSL chose to use Certification Authorities as a key component of the authenticity process, and we’ve been stuck with that decision even after having long since outgrown the circumstances in which it was originally imagined.

Lately, however, the general perception of Certification Authorities seems to be shifting from the old vibe of “total ripoff” to a new vibe of “total ripoff and also insecure.” So there has been a growing amount of talk about changing the authenticity piece of SSL. I’d like to take a moment to discuss the problem, though, so that we don’t accidentally make the same mistake twice.<

Defining The Problem

At the moment, there seems to be a general consensus that the CA system is not long for this world, and that’s a major step forward. But while almost everyone seems to agree that we should develop something else, the exact problem with what we have is not entirely well defined. Let’s look at what people have suggested the problem might be.

• There are too many CAs. This is perhaps the easiest conclusion to take away from the EFF’s SSL observatory project. By scanning the internet, the project determined that there are approximately 650 different organizations who are currently capable of signing certificates. That seems like a lot of organizations.

  But remember when there was only one? That didn’t feel any better to me. There was effectively a single vendor that could charge as much as they wanted and do whatever they wanted without any recourse. And at the time, everyone was criticizing the browsers for supporting this conspiracy by not allowing others in the club. Now that they have, they’re being criticized all over again.

  So looking at this strictly in terms of quantity feels a little too simplistic for me. Much has been made about the fact that the DHS or the Chinese government have their own CA in that list, but certainly, if the DHS or the Chinese government were made to be the only valid CA, people might feel similarly annoyed, even though the quantity would be low.

• There are a few bad apples. The subtle undertone in some of the discussions around CAs is that there are a handful of reputable CAs, and then a number of other sketchy ones. But as Chris Soghoian noted in his certified lies paper, even back when VeriSign was the only game in town, they ran a line of services that specialized in providing hosted “CALEA compliance.” Basically, the very organization who had been entrusted to facilitate intercept-free communication had a division in their company that was selling intercept services.

  While some companies in this industry have been less intelligent about managing their image than others, my feeling is that there aren’t really any existing players here who don’t have dirt on their hands. And personally, I don’t currently trust any of them.

• There’s a mixed scope. Some have suggested that the problem with all of this is the scoping. That the DHS shouldn’t be able to sign certificates for Chinese sites or vice-versa. To me this seems like a low bar. There are plenty of people who don’t trust the DHS to sign certificates for any sites, and restricting the Chinese government to Chinese sites doesn’t feel like a particularly powerful win either. So I’m also skeptical that this is the essence of the problem.

Trust Agility

I would like to suggest that the current problems with the CA system can be reduced to a single missing property. I call this property trust agility.

At the moment, if I decide that I don’t trust VeriSign or Comodo or any other CA, what can I do? The very best I could do would be to remove the offending CA’s certificate from my trusted CA database, but then some large percentage of secure sites I visit would break. I could take an ideological stand to never visit any of those sites again, but in reality, there isn’t actually an appropriate response, and this is as true for browser vendors as it is for individuals like me.

Essentially, at some point a decision was made to anchor trust in an organization like Comodo, and now we’re locked into trusting them — forever.

By contrast, there are two important elements to trust agility:

• A trust decision can be easily revised at any time. It seems reasonable to think that we’ll need to anchor our trust somewhere. That we’ll pick some entity or group of entities to authenticate our communication. And right now, I could identify a set of organizations that I would trust to do this effectively. But what seems insane is to think that I could identify an organization who I would not only be willing to trust right now, but forever, without any future possibility of changing my mind based on that organization’s performance.

  If we’re locked into making a single decision now that will effect us forever, what incentive is there for the trust provider we select to act in a way that will continue to warrant our trust?

• Individual users have the option of deciding where to anchor their trust. Some say that better scoping would fix the “bad CA problem.” That if VeriSign did something particularly egregious and were somehow restricted to only authenticating certain sites, site owners would then be able to switch to a different CA in a separate scope (as opposed to now, where VeriSign can continue to sign certificates for your site even if you’re not their customer). This, in a way, would be a limited type of trust agility.

  I think it’s worth recognizing, though, that if it’s a struggle to convince sites to deploy SSL by default to begin with, it might be a stretch to think that site operators are going to be actively making these kinds of decisions in our best interest. I also think it’s important to recognize that different people might have different notions of what is trustworthy behavior and what isn’t. A single site operator deciding who all their users are required to trust, particularly in this globalized world, doesn’t feel quite right when it’s the user’s data — not the site operator’s — that’s at risk.

  By contrast, trust agility allows individual users, not site operators or anyone else, the option of deciding who they would like to trust to provide authenticity. And it allows individuals to revise those decisions at any time.

DANE, DNSSEC, and SSL Authenticity

There has been a growing flurry of activity around leveraging DNSSEC — if it ever comes to exist — as a replacement mechanism for SSL’s authenticity piece. The basic idea is that instead of getting your site’s certificate signed by a a Certification Authority, you just put it in your DNS record. Since DNSSEC is supposed to ensure that the DNS responses a client receives are authentic, it should prevent someone from performing a man-in-the-middle attack and substituting a forged certificate. It’s essentially removing the authenticity element from SSL and using the one from DNSSEC instead.

There’s an almost immediately visceral appeal to leveraging DNSSEC this way, because DNS tends to be mentally associated with the word distributed. And distributed sounds pretty good in this context. One immediately imagines wiping Certification Authorities — who have overcharged and underprovided for so long — off the face of the internet, and replacing them with a distributed trust system instead.

But on second glance, the cold truth is that the distributed part of DNS is the information in the records, while the trust relationships are actually extremely hierarchical. This isn’t any different from the current SSL situation. Already, SSL certificates themselves are distributed throughout the internet on an individual site’s web server, with the trust relationships consolidated into the CA hierarchy.

So the “distributedness” of the two cases is exactly the same, the only difference being that adding DNSSEC to the mix would make things a little slower. But if the basic structure is the same, the next obvious question is whether there might be any improvement in how the DNSSEC trust relationships work compared to the current CA system.

It turns out that in the case of DNSSEC, there are three classes of people that we have to simultaneously trust:

• The registrars. CAs are sketchy, but this is a whole new world of sketchiness. Think, sketchasaurus. Registrars were never built or selected with security in mind, and most of them don’t have a very good track record in this area. Shouldn’t it be laughable that the current first step in deploying DNSSEC is to create an account with GoDaddy? I mean really, do you trust this guy? Forever?
• The TLDs. In the case of .com, that’s VeriSign again. Same player, same game.

  Take a moment to look at the organizations responsible for the other generic TLDs, as well as the executives that compose those organizations. Are these the people that you would choose to trust? Forever?

  In the case of country-code TLDs, this requires trusting the governments of those TLDs. Does everyone visiting hip domains like .io, .cc, or .ly trust the corresponding government behind them? Do the citizens of localized domains like .cn or .ir want to trust their governments with all of their local secure traffic? Like it or not, governments tend to be more interested in intercepting rather than securing communication.

• The root. This is ICANN. If the recent domain name seizures are any indication of the future, it seems like we might want to think carefully about forever making the decision to entrust all of our secure communication with this organization.

So unfortunately the DNSSEC trust relationships depend on sketchy organizations and governments, just like the current CA system.

Worse, far from providing increased trust agility, DNSSEC-based systems actually provide reduced trust agility. As unrealistic as it might be, I or a browser vendor do at least have the option of removing VeriSign from the trusted CA database, even if it would break authenticity with some large percentage of sites. With DNSSEC, there is no action that I or a browser vendor could take which would change the fact that VeriSign controls the .com TLD.

If we sign up to trust these people, we’re expecting them to willfully behave forever, without any incentives at all to keep them from misbehaving. The closer you look at this process, the more reminiscent it becomes. Sites create certificates, those certificates are signed by some marginal third party, and then clients have to accept those signatures without ever having the option to choose or revise who we trust. Sound familiar?

No Trust Agility, No Future

So here we are on the cusp of something. At long last, we’re finally approaching the critical mass necessary to replace the CA system that we’ve long since grown out of. But when evaluating replacement models for the CA system, the very first question we should ask is “who do I have to trust, and for how long?” If the answer is “a prescribed set of people, forever” we should probably proceed with extreme caution. I believe that if we don’t develop a solution which offers trust agility, we will inevitably find ourselves back in the exact same place that we’re currently trying to escape from.

The DNSSEC community has been struggling to get DNSSEC deployed for a long time, for the most part in the face of ambivalence. I suspect that they see the SSL authenticity piece as a potential sense of urgency which could finally make people care enough to push the DNSSEC cart over the hill, but I think we should be careful about getting on board.

I’ll write more soon about alternative authenticity pieces for SSL, which do provide trust agility, that I am considerably more inspired by.

EDIT 11/27/11— There is a video followup to this post, where I introduce Convergence.