[](<https://threatpost.com/ssl-and-future-authenticity-041111/>)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](<http://www.jwz.org/gruntle/nscpdorm.html>),
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](<https://www.eff.org/observatory>).
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](<http://www.verisign.com/>)?
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](<http://files.cloudprivacy.net/ssl-mitm.pdf>),
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](<http://www.huffingtonpost.com/2011/03/31/bob-parsons-godaddy-ceo-elephant-hunt_n_843121.html>)? 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](<http://www.theregister.co.uk/2011/02/18/fed_domain_seizure_slammed/>)
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](<http://www.thoughtcrime.org/index.html>) is a security researcher and founder of [Whisper Systems](<http://www.whispersys.com/>)._
{"id": "THREATPOST:5D40476AD2DD48D01D59FDE637153847", "vendorId": null, "type": "threatpost", "bulletinFamily": "info", "title": "SSL and the Future of Authenticity", "description": "[](<https://threatpost.com/ssl-and-future-authenticity-041111/>)In the early 90\u2019s, at the dawn of the World Wide Web, some engineers\n\nat Netscape developed a protocol for making secure HTTP requests, and \nwhat they came up with was called SSL. Given the relatively scarce body \nof knowledge concerning secure protocols at the time, as well [the intense pressure everyone at Netscape was working under](<http://www.jwz.org/gruntle/nscpdorm.html>), \ntheir efforts can only be seen as incredibly heroic. It\u2019s amazing that \nSSL has endured for as long as it has, in contrast to a number of other \nprotocols from the same vintage. We\u2019ve definitely learned a lot since \nthen, though, but the thing about protocols and APIs is that there\u2019s \nvery little going back.\n\nGenerally speaking, all secure protocols need to provide three \nthings: secrecy, integrity, and authenticity. If any of these break, the \nwhole protocol breaks. SSL doesn\u2019t do any of the three very elegantly \nby today\u2019s standards (and in many cases just barely squeaks by), but \nmost of the practical attacks we\u2019ve seen over the past ten years have \nfocused on the authenticity piece. The designers of SSL chose to use \nCertification Authorities as a key component of the authenticity \nprocess, and we\u2019ve been stuck with that decision even after having long \nsince outgrown the circumstances in which it was originally imagined.\n\nLately, however, the general perception of Certification Authorities \nseems to be shifting from the old vibe of \u201ctotal ripoff\u201d to a new vibe \nof \u201ctotal ripoff and also insecure.\u201d So there has been a growing amount \nof talk about changing the authenticity piece of SSL. I\u2019d like to take a \nmoment to discuss the problem, though, so that we don\u2019t accidentally \nmake the same mistake twice.\n\n### Defining The Problem\n\nAt the moment, there seems to be a general consensus that the CA \nsystem is not long for this world, and that\u2019s a major step forward. But \nwhile almost everyone seems to agree that we should develop something \nelse, the exact problem with what we have is not entirely well defined. \nLet\u2019s look at what people have suggested the problem might be.\n\n 1. **There are too many CAs**. This is perhaps the easiest conclusion to take away from the EFF\u2019s [SSL observatory project](<https://www.eff.org/observatory>). \nBy scanning the internet, the project determined that there are \napproximately 650 different organizations who are currently capable of \nsigning certificates. That seems like a lot of organizations.But remember when there was [only one](<http://www.verisign.com/>)? \nThat didn\u2019t feel any better to me. There was effectively a single \nvendor that could charge as much as they wanted and do whatever they \nwanted without any recourse. And at the time, everyone was criticizing \nthe browsers for supporting this conspiracy by not allowing others in \nthe club. Now that they have, they\u2019re being criticized all over again. \n\nSo \nlooking at this strictly in terms of quantity feels a little too \nsimplistic for me. Much has been made about the fact that the DHS or the \nChinese government have their own CA in that list, but certainly, if \nthe 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.\n\n 2. **There are a few bad apples.** The subtle undertone in \nsome of the discussions around CAs is that there are a handful of \nreputable CAs, and then a number of other sketchy ones. But as Chris \nSoghoian noted in his [certified lies paper](<http://files.cloudprivacy.net/ssl-mitm.pdf>), \neven back when VeriSign was the only game in town, they ran a line of \nservices that specialized in providing hosted \u201cCALEA compliance.\u201d \nBasically, the very organization who had been entrusted to facilitate \nintercept-free communication had a division in their company that was \nselling intercept services.While some companies in this industry have \nbeen less intelligent about managing their image than others, my \nfeeling is that there aren\u2019t really any existing players here who don\u2019t \nhave dirt on their hands. And personally, I don\u2019t currently trust any of \nthem.\n 3. **There\u2019s a mixed scope. **Some have suggested that the \nproblem with all of this is the scoping. That the DHS shouldn\u2019t be able \nto sign certificates for Chinese sites or vice-versa. To me this seems \nlike a low bar. There are plenty of people who don\u2019t trust the DHS to \nsign certificates for any sites, and restricting the Chinese government \nto Chinese sites doesn\u2019t feel like a particularly powerful win either. \nSo I\u2019m also skeptical that this is the essence of the problem.** **\n\n### Trust Agility\n\nI would like to suggest that the current problems with the CA system \ncan be reduced to a single missing property. I call this property _trust agility_.\n\nAt the moment, if I decide that I don\u2019t trust VeriSign or Comodo or \nany other CA, what can I do? The very best I could do would be to remove \nthe offending CA\u2019s certificate from my trusted CA database, but then \nsome large percentage of secure sites I visit would break. I could take \nan ideological stand to never visit any of those sites again, but in \nreality, there isn\u2019t actually an appropriate response, and this is as \ntrue for browser vendors as it is for individuals like me.\n\nEssentially, at some point a decision was made to anchor trust in an \norganization like Comodo, and now we\u2019re locked into trusting them \u2014 _forever_.\n\nBy contrast, there are two important elements to trust agility:\n\n 1. **A trust decision can be easily revised at any time**. \nIt seems reasonable to think that we\u2019ll need to anchor our trust \nsomewhere. That we\u2019ll pick some entity or group of entities to \nauthenticate our communication. And right now, I could identify a set of \norganizations that I would trust to do this effectively. But what seems \n_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\u2019s performance.If \nwe\u2019re locked into making a single decision now that will effect us \nforever, what incentive is there for the trust provider we select to act \nin a way that will continue to warrant our trust?\n 2. **Individual users have the option of deciding where to anchor their trust**. \nSome say that better scoping would fix the \u201cbad CA problem.\u201d That if \nVeriSign did something particularly egregious and were somehow \nrestricted to only authenticating certain sites, site owners would then \nbe able to switch to a different CA in a separate scope (as opposed to \nnow, where VeriSign can continue to sign certificates for your site \neven if you\u2019re not their customer). This, in a way, would be a limited \ntype of trust agility.I think it\u2019s worth recognizing, though, that \nif it\u2019s a struggle to convince sites to deploy SSL by default to begin \nwith, it might be a stretch to think that site operators are going to \nbe actively making these kinds of decisions in our best interest. I \nalso think it\u2019s important to recognize that different people might have \ndifferent notions of what is trustworthy behavior and what isn\u2019t. A \nsingle site operator deciding who all their users are required to trust, \nparticularly in this globalized world, doesn\u2019t feel quite right when \nit\u2019s the user\u2019s data \u2014 not the site operator\u2019s \u2014 that\u2019s at risk. \n\nBy \ncontrast, trust agility allows individual users, not site operators or \nanyone else, the option of deciding who they would like to trust to \nprovide authenticity. And it allows individuals to revise those \ndecisions at any time.\n\n### DANE, DNSSEC, and SSL Authenticity\n\nThere has been a growing flurry of activity around leveraging DNSSEC \u2014 \nif it ever comes to exist \u2014 as a replacement mechanism for SSL\u2019s \nauthenticity piece. The basic idea is that instead of getting your \nsite\u2019s certificate signed by a a Certification Authority, you just put \nit in your DNS record. Since DNSSEC is supposed to ensure that the DNS \nresponses a client receives are authentic, it should prevent someone \nfrom performing a man-in-the-middle attack and substituting a forged \ncertificate. It\u2019s essentially removing the authenticity element from SSL \nand using the one from DNSSEC instead.\n\nThere\u2019s an almost immediately visceral appeal to leveraging DNSSEC \nthis way, because DNS tends to be mentally associated with the word _distributed_. \nAnd distributed sounds pretty good in this context. One immediately \nimagines wiping Certification Authorities \u2014 who have overcharged and \nunderprovided for so long \u2014 off the face of the internet, and replacing \nthem with a _distributed_ trust system instead.\n\nBut on second glance, the cold truth is that the _distributed_ \npart of DNS is the information in the records, while the trust \nrelationships are actually extremely hierarchical. This isn\u2019t any \ndifferent from the current SSL situation. Already, SSL certificates \nthemselves are _distributed_ throughout the internet on an individual site\u2019s web server, with the trust relationships consolidated into the CA hierarchy.\n\nSo the \u201cdistributedness\u201d of the two cases is exactly the same, the \nonly difference being that adding DNSSEC to the mix would make things a \nlittle slower. But if the basic structure is the same, the next obvious \nquestion is whether there might be any improvement in how the DNSSEC \ntrust relationships work compared to the current CA system.\n\nIt turns out that in the case of DNSSEC, there are three classes of people that we have to simultaneously trust:\n\n 1. **The registrars**. CAs are sketchy, but this is a \nwhole new world of sketchiness. Think, sketchasaurus. Registrars were \nnever built or selected with security in mind, and most of them don\u2019t \nhave a very good track record in this area. Shouldn\u2019t it be laughable \nthat the current first step in deploying DNSSEC is to create an account \nwith GoDaddy? I mean really, do you trust [this guy](<http://www.huffingtonpost.com/2011/03/31/bob-parsons-godaddy-ceo-elephant-hunt_n_843121.html>)? Forever?\n 2. **The TLDs**. In the case of .com, that\u2019s VeriSign again. Same player, same game.Take \na moment to look at the organizations responsible for the other generic \nTLDs, as well as the executives that compose those organizations. Are \nthese the people that you would _choose_ to trust? Forever? \n\nIn \nthe case of country-code TLDs, this requires trusting the governments \nof those TLDs. Does everyone visiting hip domains like .io, .cc, or .ly \ntrust the corresponding government behind them? Do the citizens of \nlocalized domains like .cn or .ir want to trust their governments with \nall of their local secure traffic? Like it or not, governments tend to \nbe more interested in intercepting rather than securing communication.\n\n 3. **The root**. This is ICANN. If the recent [domain name seizures](<http://www.theregister.co.uk/2011/02/18/fed_domain_seizure_slammed/>) \nare any indication of the future, it seems like we might want to think \ncarefully about forever making the decision to entrust all of our secure \ncommunication with this organization.\n\nSo unfortunately the DNSSEC trust relationships depend on sketchy \norganizations and governments, just like the current CA system.\n\nWorse, far from providing increased trust agility, DNSSEC-based \nsystems actually provide reduced trust agility. As unrealistic as it \nmight be, I or a browser vendor do at least have the option of removing \nVeriSign from the trusted CA database, even if it would break \nauthenticity with some large percentage of sites. With DNSSEC, there is \nno action that I or a browser vendor could take which would change the \nfact that VeriSign controls the .com TLD.\n\nIf we sign up to trust these people, we\u2019re expecting them to \nwillfully behave forever, without any incentives at all to keep them \nfrom misbehaving. The closer you look at this process, the more \nreminiscent it becomes. Sites create certificates, those certificates \nare signed by some marginal third party, and then clients have to accept \nthose signatures without ever having the option to choose or revise who \nwe trust. Sound familiar?\n\n### No Trust Agility, No Future\n\nSo here we are on the cusp of something. At long last, we\u2019re finally \napproaching the critical mass necessary to replace the CA system that \nwe\u2019ve long since grown out of. But when evaluating replacement models \nfor the CA system, the very first question we should ask is \u201cwho do I \nhave to trust, and for how long?\u201d If the answer is \u201ca proscribed set of \npeople, forever\u201d we should probably proceed with extreme caution. I \nbelieve that if we don\u2019t develop a solution which offers trust agility, \nwe will inevitably find ourselves back in the exact same place that \nwe\u2019re currently trying to escape from.\n\nThe DNSSEC community has been struggling to get DNSSEC deployed for a \nlong time, for the most part in the face of ambivalence. I suspect that \nthey see the SSL authenticity piece as a potential sense of urgency \nwhich could finally make people care enough to push the DNSSEC cart over \nthe hill, but I think we should be careful about getting on board.\n\nI\u2019ll write more soon about alternative authenticity pieces for SSL, \nwhich do provide trust agility, that I am considerably more inspired by.\n\n_[Moxie Marlinspike](<http://www.thoughtcrime.org/index.html>) is a security researcher and founder of [Whisper Systems](<http://www.whispersys.com/>)._\n", "published": "2011-04-11T23:17:08", "modified": "2018-08-15T10:12:47", "cvss": {"score": 0.0, "vector": "NONE"}, "cvss2": {}, "cvss3": {}, "href": "https://threatpost.com/ssl-and-future-authenticity-041111/75125/", "reporter": "Moxie Marlinspike", "references": ["https://threatpost.com/ssl-and-future-authenticity-041111/", "http://www.jwz.org/gruntle/nscpdorm.html", "https://www.eff.org/observatory", "http://www.verisign.com/", "http://files.cloudprivacy.net/ssl-mitm.pdf", "http://www.huffingtonpost.com/2011/03/31/bob-parsons-godaddy-ceo-elephant-hunt_n_843121.html", "http://www.theregister.co.uk/2011/02/18/fed_domain_seizure_slammed/", "http://www.thoughtcrime.org/index.html", "http://www.whispersys.com/"], "cvelist": [], "immutableFields": [], "lastseen": "2018-10-06T23:05:48", "viewCount": 3, "enchantments": {"score": {"value": -0.4, "vector": "NONE"}, "dependencies": {}, "backreferences": {"references": [{"type": "nessus", "idList": ["FREEBSD_PKG_810DF820366411E18FE300215C6A37BB.NASL"]}, {"type": "threatpost", "idList": ["THREATPOST:050A36E6453D4472A2734DA342E95366"]}]}, "exploitation": null, "vulnersScore": -0.4}, "_state": {"dependencies": 1678917980, "score": 1678916296, "epss": 1678938645}, "_internal": {"score_hash": "8cc4f3ca173efd632ee6a8b9b23a8058"}}
SSL and the Future of Authenticity