SSL and the Future of Authenticity

By Moxie MarlinspikeIn 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.

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.

Suggested articles

Discussion

  • Michael on

    I see 'trust agility' being a step in the right direction from the almost implicit trust given by CAs to a less implicit and more adaptive model of trust. However I still see that there is an issue with seeing trust in a binary fashion of trusted or untrusted. I would rather use the term 'trust sufficiency' which is whether the level of trust that I have in a particular service is greater than the level of trust I require for that service.

    Do you agree?

  • aBionic on

    Moxie and DanKaminsky's work on SSL and DNS security issues have been really inspiring... I just hoped more of DANE... it has been quite some time hearing not much advancement

  • Anonymous on

    But would a government who demands a CA to silently spy upon citizens for national security reasons adopt and endorse a system that they themselves would not be able to subvert? 

    I've always believed the biggest fight in infosec is a fight against public ignorance.  We are not secure beings having an insecure moment, we are insecure beings trying for a secure moment.

  • Melinda on

    It seems pretty clear that the ability to drop an installed trust anchor is an instance of revocation.  Deleting its root cert from your cache is pretty straightforward, but one of the things we've learned in the past month or so is that not only is revocation kind of broken, nobody seems to trust that it actually works.

    Don't know if you're familiar with RFC 5934 (trust anchor management protocol) but it provides a protocol tool for inserting, removing, etc. trust anchors.  That doesn't go to the much more complicated question of how to decide who to trust, and it's not clear to me that there's a good answer for that one.

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.