How does this proposal compare to TACK: http://tack.io ?
What about Moxie's other project, Convergence? http://convergence.io/
Let’s Take Back The Certificate Authority
11–15 of 15 posts
Re: Let’s Take Back The Certificate Authority
#12A 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...
[2]: http://blog.jackdb.com/post/55178133114/using-self-signed-ss...
[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...
Re: Let’s Take Back The Certificate Authority
#13Doesn't this already exist in the form of CAcert?
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.
Re: Let’s Take Back The Certificate Authority
#14Doesn't this already exist in the form of CAcert?
Agreed: For working within the current systems, cacert (www.cacert.org) seems like a perfect fit.
Re: Let’s Take Back The Certificate Authority
#15Earlier quoted context omitted.
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.
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 )
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.