SSL and the Future of Authenticity

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.

1. 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.

2. 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.
3. 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:

1. 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?
2. 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:

1. 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?
2. 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.

3. 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 proscribed 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.

Moxie Marlinspike is a security researcher and founder of Whisper Systems.