Hacker News Reader

Comment by z3t4 | Hacker News Reader

Isn't SSL/TLS certificates broken when all you have to do is to add one root certificate to MITM everyone else's SSL/TSL?

View on HN

Isn't adding new root certificates basically the same attack vector as just turning off or routing around your SSL? Who can mess with your certificate store who can't also just run whatever code on your machine?

Yes it is, and we all know it, but we are apparently unable to fix it.

Yup. What's really, really sad (and an indictment of our entire industry) is that RFCs 2692[1] & 2693[2] provided a mechanism to address exactly this point, but were completely ignored despite being correct.

XPKI attempted to bind a server private key and some sort of global identity, but that only really makes sense with some sort of global identity root. Not wanting to trust all identities to a single CA, we instead … trust all identities to all CAs, which seems a strictly worse situation.

And it turns out that we don't particularly want to bind servers to public identities most of the time, anyway: essentially no-one ever opens a certificate to see what it actually certifies. Amazon is amazon.com; Google is google.com; what people care about is if the server they are visiting is indeed the one they care about visiting — which means that all they really want is a binding of a server to a DNS name.

The way this should work is that (ultimately) the IETF should issue a certificate to each domain holder, valid for the lifetime of that domain's registration. The domain holder would then be able to issue certificates to any subdomain of the domain he holds (e.g. the U.S. government could issue a certificate to va.us, which could then turn around and issue a certificate to fairfax.va.us).

The CA business is a racket. XPKI is fundamentally broken, and no-one cares. We've had a solution for twenty years, and no-one has deployed it.

[1] https://tools.ietf.org/html/rfc2692 [2] https://www.ietf.org/rfc/rfc2693.txt

P.s.: Funny how a Google search can return such different URLs for the same RFCs…

Is it broken when a CA can be compromised without consequence? Is it broken when bad actors can have root certs installed in most browsers?

Yes, it's broken. It's been broken for a very long time.

but all decentralised proposals I've ever seen fall over at scale, or become basically the CA system when applied at a big enough scale.

I would like to be pointed out to be wrong here, though. the current CA system bugs me for the "one CA compromised" aspect.

What about DANE? I would imagine it has potential to do away with CA...

https://www.imperialviolet.org/2015/01/17/notdane.html

Well that definitely answers my question. Thank you. What about something like certificate blockchain?

e.g. https://github.com/okTurtles/dnschain

It already exists and is called Certificate Transparency: https://www.certificate-transparency.org/

holy sh*t it's learning day today! Thanks!

In a way it's broken for the same reason than the banking system was: too big to fail. So many websites rely on a few CA that we can't allow to fail, otherwise we break the internet.

I wonder if we shouldn't adopt a solution similar to what was adopted for banks: a plan for orderly failure. Having a protocole, at least for DV certificates, to easily switch all your website to another CA. All CA would have to implement the same API, and all web servers would be able to consume that API. The same API would be used for auto-renewing certificates. Effectively generalising let's encrypt for commercial certificates.

A protocol should definitely be in place for that, all the updates I do are handled just by using apt-get except for certificates. Like I don't want to handle myself anything related to certificates (including the list of ciphers, the generation of new certificates, the compromised CAs ...), the current certificate system feels like the equivalent of installing updates with .tar.gz archives.

I think that's one of the goals of Let's Encrypt, by developing the ACME protocol, which will be submitted as a standard RFC: https://ietf-wg-acme.github.io/acme/

Well there's public key pinning which helps.

Which is by itself broken. Large websites exchange certificates very often, rendering pinning useless. Unless you are talking not about pinning but about pinning by external actor, such as Google. And that is just moving your own security from hands of CA to hands of Google.

You can pin a certificate higher in the chain, like the root cert of your CA. That way, you can still rotate your own cert, but an attacker couldn't just install a new root cert in the machine, they would have to get a cert from the same CA as your own.

Do any of the publicly available CAs provide a guarantee that you can pin them? I remember there was at least one case of someone pinning a CA and making the news because the page could not load anymore.

I can't say I know, but I don't think they can simply replace them at will, otherwise wouldn't existing certs just stop working?

The intermediates can be replaced without issues, as long as they link to the same root certificates. That's the standard way to rotate them when they expire, or get compromised.

Ah, yes, but my suggestion was to pin the root.

CAs will not arbitrarily throw out their root certificates (they're quite expensive and valuable), so you'll be fine pinning to a root. I'd advise against it when you use OV or EV certificates though, as it'd allow for a DV certificate to still work.

When are you talking about them being replaced? Because I thought website certificates embed the signature of the signer (the intermediate), so if the intermediate is revoked, my website's certificate won't work anymore. If that's the case I should be fairly safe pinning the intermediate for as long as my website certificate is valid.

You can pin (multiple) private keys. Usually, you don't have to change your private key when getting a new certificate (for example, with Lets Encrypt).

If you do want to change private keys regularly, generate them beforehand and pin them.

Dan Kaminsky had a good talk[1] regarding this on 26c3, where he essentially argued that the only reason we have TLS at all is because companies selling stuff over the Internet wants to make it seem secure for the customer. State actors or large companies interested in data mining are not that interested in committing credit card fraud, so every one just accepts the PKI status quo more or less.

Or that was what I took away from what he said. I havn't seen the complete talk since he held it.

[1] https://events.ccc.de/congress/2009/Fahrplan/events/3658.en....

That may have been true with the original SSL, but consider all the B2B APIs, VPNs, and other critical stuff happening over TLS these days.

The problem is the PKI. For your own services, you can have your own PKI, and the issue of "trust one, trust all" is not really an issue anymore because you would only trust your own certificates for your own services.

The problem is that pretty much any CA trusted by your OS/browser can issue certificates that allows anyone who can control your network to MITM you.

A solution for this would be DNSSEC, where only .com would be able to sign foo.com, bar.com and other .com domains. But still, would you trust the issuer of .com certificates?

Reply on news.ycombinator.com