

Let’s Take Back The Certificate Authority - mephux
https://medium.com/i-m-h-o/ccbb7c52f2ac

======
reaperhulk
I ran the technical side of a global CA for 5 years (left the industry early
this year) and I can tell you that while validation (outside of EV) is
relatively simple, the technical/legal/audit aspects add up to a significant
cost.

If you want to run a CA you need to obtain sufficient funding (on an ongoing
basis, these aren't all one-time costs) to do things properly. Properly means
expensive audits, expensive HSMs, expensive secure rooms with multi-factor
authentication to enter, auditing of all actions, long-term record retention,
reliable and performant OCSP responders, endless documentation (DR, secure
hardware lifecycle policies, etc), being an active member of the CABForum to
drive your agenda and keep abreast of changing industry requirements, and
much, much more. Of course, by doing so you are attempting to upend a multi-
billion dollar industry, so expect a political fight with the CAs and
potentially the browsers as well...

These problems are part of what lead people to prefer replacing the industry
(DANE, Convergence, TACK) over building a non-profit CA in the existing model.
Of course, replacement comes with its own huge set of obstacles.

All that said, if you're a company with a bunch of money you want to spend on
this problem, let me know. I am willing to lend a hand.

------
jackweirdy
I disagree with this completely. The CA Model is absolutely flawed, and this
is just patching a flawed model. I'd love to see a push for
[DANE]([https://en.wikipedia.org/wiki/DNS-
based_Authentication_of_Na...](https://en.wikipedia.org/wiki/DNS-
based_Authentication_of_Named_Entities)) - where you publish your public key
in DNS. When doubled with DNSSEC, this means your IP address is irrefutably
tied to your domain and so is your TLS public key.

~~~
chopin
DNSSEC has the problem that you rely on root certificates as well - which are
ultimately controlled by state actors. Where this goes we know already.

~~~
jackweirdy
Well we have a hell of a lot more transparency about where that key is, who
generated and has access to it. There's a video of the entire ceremony online
somewhere, at the moment I can only find [this
summary]([https://www.youtube.com/watch?v=b9j-sfP9GUU](https://www.youtube.com/watch?v=b9j-sfP9GUU))

~~~
chopin
My critique goes more in the direction of DNSSEC being a centralized
infrastructure. I didn't mean that it is easily subverted but its possible,
especially for an US state actor. Its definitely more transparent as SSL CA's
for sure. However, for my communications I'd like rather rely on an
infrastructure which is independent from centralized resources.

------
sehrope
A lot of folks don't realize this but it's not just web browsers that you need
to worry about. When your app connects over SSL to any service that it's
consuming you need to be properly authenticating the remote server. For
external HTTP requests (ex: to an external REST services) many programming
languages/environments piggy back on the host machine's list of trusted roots
(ie. the same ones that your browser uses) but a lot do not. They may just
skip over the authentication piece of the SSL handshake.

This is _especially_ true for database drivers. If your database driver
includes a "use SSL" flag but you're not actually specifying a pre-shared
certificate to authenticate the remote server then it's probably not
authenticating the remote server[1]. Think about that for a second ... How
would it?

I wrote about this a little while back[2] and gave a talk that went into this
in a bit more detail this week (slides should be up next week). The gist of it
is that if you don't authenticate the remote server (by authenticating its SSL
cert) you're vulnerable to a MITM attack _every_ time you connect. Not just
the first time, _every time_. With SSH we're used to pinning remote host keys
the first time you connect but with SSL there's no such thing[3] and you have
to be careful to handle it properly.

[1]: I say "probably" here because it's technically possible that your remote
server has an SSL certificate that is signed by the same set of trusted CAs
that you use for HTTP requests _and_ your DB driver actually validates it but
it's not likely. Most database SSL certificates are either self-signed or
self-signed via a CA signing cert controlled by a DBaaS. For example for RDS,
Amazon signs the SSL certificates for all MySQL databases with a single CA
signing cert:
[http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_M...](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_MySQL.html#MySQL.Concepts.SSLSupport)

[2]: [http://blog.jackdb.com/post/55178133114/using-self-signed-
ss...](http://blog.jackdb.com/post/55178133114/using-self-signed-ssl-
certificates-with-jackdb)

[3]: No reason there couldn't be SSL cert pinning and it's something we've
considered for our product. However you can't really automate it (you need a
user to say "this is okay...") so we decided to have it be a manual step that
you can just click to fetch/import:
[http://blog.jackdb.com/post/55349902000/auto-importing-
ssl-c...](http://blog.jackdb.com/post/55349902000/auto-importing-ssl-
certificates-into-jackdb)

------
comex
Doesn't this already exist in the form of CAcert?

~~~
reaperhulk
CAcert doesn't have a WebTrust audit and is therefore not included in many
cases. They've talked about audits in the past but every time it comes up it
eventually stalls. I have no insight into their process, but I'd suspect it's
a combination of people who oppose the concept of WebTrust audits and also
that when they speak to auditors they discover they would fail such audits.

------
anon1385
How does this proposal compare to TACK: [http://tack.io](http://tack.io) ?

~~~
martindale
What about Moxie's other project, Convergence?
[http://convergence.io/](http://convergence.io/)

