Hacker News Reader

Comment by mangeletti | Hacker News Reader

So, one CA to rule then all?

There's a scenario (simplified for illustration, but entirely possible) that's normally not a huge risk because there are many CAs, and they are private, for-profit companies that have an economic incentive to protect you and your certificate's ability to assure end users that a conversation's privacy won't be compromised.

1) browser requests site via SSL

2) MITM says, "let's chat - here's my cert"

3) browser asks, "is this cert legit for this domain?"

4) MITM says, "yes, CA gave us this, because of FISA, to give to you as proof"

5) browser says, "ok, let's chat"

I'm not trying to spread FUD, but if you're NSA and you've been asking CAs for their master keys for years, doesn't a single CA sound great (free and easy == market consolidation), and doesn't EFF seem like the perfect vector for a Trojan horse like this, given its popularity and trust among hacker types gained in recent years?

View on HN

We will look for ways to mitigate the risk of misissuing for any reason, including because someone tries to coerce us to misissue. One approach to this that's interesting is Certificate Transparency.

http://www.certificate-transparency.org/

There's also HPKP, TACK, and DANE, plus the prospect of having more distributed cert scans producing databases of all the publicly visible certs that people are encountering on the web.

DANE is the way to go forward. Have your TLD CA sign your domain key and sign your web certificates with your own key.

Only one "root CA" to trust per TLD, and it's free if you own a TLD that supports DNSSEC (most do these days).

Now we just need the DANE check built into the browser without any plugins that require installation.

I'm not sure I follow that line of reasoning. Each CA is independently and completely able to issue certificates (not counting EV, but let's leave that out). There are hundreds of CAs. Depending on your trust store, some of them are literally owned by the US Department of Defense. Others are owned by the Chinese government.

How does having _fewer_ CAs make anything easier? Why is the EFF a better route than any of the various other companies that have gotten themselves in the CA program? And given that all the CAs are equivalently trusted at a technical level, why does the human trust afforded the EFF affect whether it's a better target?

This is not an attempt to reduce the CA system to a single CA. The intent here is to provide a simple and free way for anyone to get basic DV certs. If we can also contribute to CA best practices, and help improve the CA system in general, we'd like to do that too.

Let's Encrypt is only planning to issue DV certificates, since that is the only type that can be issued in a fully automated way. Many organizations will want something other than DV, and they'll have to get such certs from other CAs.

Also, our software and protocols are open so that other CAs can make use of them.

Let's Encrypt is going to publish records of everything it signs, either with Certificate Transparency or some other mechanism.

Browsers will be able to check any cert signed by the Let's Encrypt CA against the published list. If there's a discrepancy, that will be immediately detectable.

Out of curiosity, what if MITM says, "include me in this list for IP <user IP>"? If the check is not done in a way that solves the byzantine generals problem, I don't see how this feature provides any more protection, other than one more hoop to jump through.

Certificate Transparency tries to solve the Byzantine Generals problem (up to high levels of collusion). Take a peek at their design -- it's pretty interesting!

It does rely on the legitimate site owner actively checking the records to notice the misissuance. Maybe that process could be automated somehow.

Is that automation not what the monitors and auditors do? http://www.certificate-transparency.org/what-is-ct

If you can corrupt both the authority signing the certificate and the authority signing the Certificate Transparency append-only log, you can successfully MITM a connection.

However, if the client is ever subsequently on a non-MITMed connection, it can detect the certificate disappearing from the append-only log - and the signed certificate and signed append-only log constitute irrefutable evidence that the two authorities were compromised.

As all legitimately issued certificates are in the Certificate Transparency logs, browser vendors can grandfather them in so they keep working after they drop the CA certificate from the trust root. This kills the CA.

This would give CAs the power to refuse requests from the NSA, because their hands are tied - no matter what coercion the NSA threatens, the CA can't issue an MITM certificate without getting shut down.

Obviously it remains to be seen whether this will work in practice.

The NSA (or any other agency) only has to coerce any single CA to cooperate. As long as it's in the standard set shipped with browsers, its certificates are accepted.

And pretty much every major government directly or indirectly controls one or multiple CAs that are in the standard set.

Reply on news.ycombinator.com