
CA Security Council – Myths about CA's - andygambles
https://casecurity.org/myths/
======
tptacek
This is truly impressive. Nine "myths" presented, of which _eight_ are self-
evidently true. The only thing on this page that anyone can credibly argue
about is whether SSL/TLS is so antiquated that it demands a ground-up
replacement.

~~~
ghshephard
Obviously you know 1000x more about this than I do, so I'm interesting in your
take on: "CAs do not provide value".

Is it really the case that anyone can get a CA to issue a certificate for
"Wellsfargo.com?" Doesn't the CA provide some level of value to the consumer,
that they really are connecting to someone who was able to prove they have
control over the "wellsfargo" domain, or at least their DNS server? And,
likewise, doesn't the CA provide some level of value to the Bank, who wants
the nice "Green Lock" appearing in the URL bar?

Nobody is arguing that the system is bulletproof, that all consumers are
educated to watch for a "green" HTTPS connection, and that 100% of
certificates have always been assigned to the proper party, and only the
proper party - but, by and large, isn't the job of a CA (and the value that
they offer), to provide some level of assurance that you really are connecting
to the website that you think you are connecting to? And, haven't they
provided a lot of that value over the last decade or so?

~~~
michaelbuckbee
SSL/TLS Certs are trying to deal with two separate problems:

1\. Over the wire encryption - where most of the criticisms in this thread are
focused. Which I will also defer to tptacek's knowledge.

2\. Site identification as an anti-phishing mechanism. For even the cheapest
certs (domain+email validated) - the CAs will reject SSL cert requests for
anything that might be a phishing target. Detecting "wellsfargo.com" is pretty
easy, where it gets tricky is things like "wellsforgo.com", "wellsfàrgo.com"
etc.

This has even gotten weird as the browser makers have started to really de-
emphasize domain certs vs ev certs (cheap vs expensive), to the point where in
most cases now having a domain cert does not know green at all.

Screenshots: [https://www.expeditedssl.com/pages/visual-security-
browser-s...](https://www.expeditedssl.com/pages/visual-security-browser-ssl-
icons-and-design)

------
contingencies
"Hi, we're an association of all the people making money from _x_. Let us tell
you why the highly appealing _x_ , responsible for saving the world from evil
daemons, should remain in widespread use despite extensive evidence to the
contrary."

"Those of us providing _x_ are really doing it well, and have to pass
stringent checks, but those are too complex to go in to so please accept my
hand-waving in lieu of actual evidence."

"We've been providing _x_ for so long, obviously we're great at it and it's
something that needs to keep being provided."

"We have different flavors of _x_ , by the way: choose from vanilla, rainbow,
or secure cookies and cream!"

"We go to conferences and sometimes talk to people. This makes us really
important and stuff. Are you impressed yet?"

"Despite there nominally being 600 providers of _x_ , in practice only 65 are
'in the club', and 7 of us have formed an international cartel!"

"Some of us somewhat recently twiddled some configuration bits, therefore we
are clearly on top of this _x_ -manufacturing technology stuff."

"It's true! Our reputation, as _x_ providers in the lucrative cartel, is of
critical importance. We've even paid someone to draft this drivel. Are you
convinced yet?"

"It's not true what those people say - 'Once you take _x_ there's no going
back' \- you can vomit, have your stomach pumped, or induce psychosis or
hypnosis for the duration of the undesired effects. Of course, you can't get
anything done for that period of time, which may occur at the worst possible
moment: when booking a plane ticket, making a critical banking transaction, or
communicating about the human rights abuses of your government. But that's OK,
because there's clearly a way to turn off our pervasive control of your
'highly secure' communications... right?"

------
oleganza
Remember that CAs were invented as a way to solve two UX and security issues:

1\. When I go to google.com, I want to be sure it's the same google.com
everyone else connects to.

2\. When I go to google.com many more times, I want to get to the same
google.com as I was visiting before.

It's relatively easy to do #2 (SSH was doing it for years), but it's very hard
task to do #1 correctly. The first problem is essentially a problem of global
consensus. It can only be solved using Bitcoin blockchain, poorly simulated
with Certificate Authorities, or left alone as SSH did (which is fine for
hackers connecting to their own machines, but not fine for global name
system).

If anyone is interested in improving SSL/TLS, the way forward is to use
blockchain to associate names and public keys so that users could know for
sure that they connect to the same name as anyone else without trusting any
CAs. Of course, that'd require development not only of a new DNS-meets-SSL
protocol, but also robust lightweight Bitcoin nodes and correct UX
conventions. That's hard, time consuming, but the only way forward out of the
current mess.

Relevant quote from Nick Szabo ("leaving small holes unplugged"):
[http://blog.oleganza.com/post/69174500046/leaving-small-
hole...](http://blog.oleganza.com/post/69174500046/leaving-small-holes-
unplugged)

~~~
valarauca1
>It can only be solved using Bitcoin blockchain

Could you please elaborate?

~~~
oleganza
Proving that you see the same data as everyone else is Byzantine General's
Problem which cannot be solved in information theory. However, it can be
solved practically if there's a single hugely powerful chain of proofs-of-work
referencing that data. Today it is Bitcoin's blockchain.

What you want to prove to yourself is that if "google.com" is associated with
public key "04cafebabe", that association is also visible to everyone else
(provided other people follow the same protocol).

The distributed DNS+SSL protocol could look like this (simplified):

1) To register a name "google.com", check that it's not registered yet (see
below). If not, create a special Bitcoin transaction ("registration tx") that
encodes both the name and the public key of the SSL certificate used by that
server.

2) To check who owns the name "google.com", find the earliest "registration
tx" on the blockchain (other people could add more, but only the first one is
considered valid). If the name is 100 blocks deep, trust the public key
associated with it.

The protocol can (and should be) extended to allow transferring the name to
new public keys, you may check how Namecoin does it.

What you get in result is that every single user can be sure that they see the
same up-to-date public key identifying "google.com" without any trusted
Certificate Authorities who have failed at this promise multiple times
already.

As a nice side effect, name allocation and trade is also decentralized. If you
own name "google.com" and users respect the protocol, no one can take this
name from you or censor your sale of that name to someone else. Also, you are
free to register your own name without asking for anyone's permission and
paying fees.

~~~
valarauca1
The fundamental problem is the first come first name nature.

It is not correct.

If I monitor DNS changes, and when new host names pop up. If I have the
resources I can make a block-chain transaction automatically.

How will my transactions (provided I also create a new walletID) for each
transaction be framed as fraudulent? Without community or authoritative over-
site?

~~~
Karunamon
I don't understand this - domain names are first come first serve anyways. Why
would it be bad to have the security part of the domain handled at the same
time, in the same transaction as the registration part?

~~~
valarauca1
Namecoin works great in a vacuum. It would be amazing if DNS already didn't
exist.

But using namecoin with DNS allows for duplicate and erroneous entries in one
or the other. (DNS record != Namecoin record).

Currently most namecoin advocates pretend the former is the case. And it
isn't, because have DNS currently. Namecoin is a complete re-invention of the
system. Not a iterative improvement.

My issue is that in its current state one can make a namecoin entry that is
correct as far as namecoin is concerned, and incorrect as far as DNSSEC or
standard DNS is concerned. Thus rendering the system in a weird state.

------
pilif
_> As are subject to various checks and balances, including third-party
qualified audits through WebTrust or ETSI and strict criteria set forth by
leading browsers, before they are accepted in browser root stores._

yes. And in cases like DigiNotar and other less famous CA (and intermediate)
compromises, we've seen how well that works.

------
AlyssaRowan
The big elephant in the room is the intermediate certificates; conveniently
unaddressed in this glib "everything's fine" piece.

Everything's _not_ fine. We're only just beginning to tackle deep-seated
problems in TLS and improve things, but we're probably stuck with some of the
most regrettable decisions, like x.509 and the CAs.

We need Certificate Transparency most of all for intermediates. The roots may
be small in number, and many of them a little outdated, but the number of
still-unaccounted-for intermediates worries me. How many have no path and/or
usage restriction? Who has them? Are _they_ all regulated? Because they should
be. Some are likely in the hands of attackers. We should be accounting for
them all.

The CA model, as it stands today, is inferior to DNSSEC for DV. Yes, under
DNSSEC, those above you in the chain of authority can fake DNS responses, but
at least no-one _else_ can. If the DNS root is removed from the control of a
potential attacker (not that they'd ever get away with it, but still) then I
view DANE pinning as strictly superior to DV certificates (although still not
perfect, but nor is DNS). The CA model may still have use with EV.

The problem of a transparency equivalent for DNSSEC remains unsolved, and is
under tension with it being considered a bad thing to be able to enumerate
domains and hosts (although it is in practice very practical to do so anyway).

~~~
iancarroll
Mozilla addresses this problem by requiring all CAs to disclose every
intermediary certificate they've issued.

CT will hopefully become widespread, given Chrome will kill EV indicators
without it.

~~~
andygambles
Chrome is practically forcing CA's to adopt CT by removing green address bars
for non-CT certs.

------
peterwwillis
Highly amusing that a security council refers to the technology it oversees
using a name that was replaced 14 years ago because it was considered too
insecure (and the IETF wanted their own name)

~~~
iancarroll
They're used interchangeably pretty much everywhere.

~~~
peterwwillis
Don't you think that's just stupid, though? First of all they're not the same
things at all, secondly nobody actually uses SSL 3.0, and third it's now
broken due to POODLE. TLS rocks, SSL sucks. Yet we keep saying SSL when we
mean TLS.

~~~
iancarroll
Do I think its stupid? Yeah. But honestly, it's used so people don't ask
"what's that?". I don't think it undermines someone's credibility.

~~~
peterwwillis
This is a page that purports to dispel misconceptions about the industry's
core technology. This would probably be the perfect place to add a section
called "I heard SSL is broken because <list of obsolete flaws in SSL>".

------
zobzu
Load of bs with some truth to it but avoiding to mention whats important. As
per cab forum rules the 3rd party audit is about having scripts for
generation, a determined (by yourself) set of ppl during ceremony.... Which
you can tape and send to a paid auditor of your choice. Thats the only
check/balance made.

The rest is in the same vein. Sounds good until you know the details. Then it
doesnt sound all that safe or great anymore - more of a money making machine.

Turns out this site is made to defend these financial interests.

------
andygambles
Is the CA Security Council doing a good job of providing information about
what they do and why we should still trust CA's?

