Remix.run Logo
grey-area 3 days ago

Since you’ve thought about it a lot, in an ideal world, should CAs exist at all?

mcpherrinm 3 days ago | parent | next [-]

There's no such thing as an ideal world, just the one we have.

Let's Encrypt was founded with a goal of rapidly (within a few years) helping get the web to as close to 100% encrypted as we could. And we've succeeded.

I don't think we could have achieved that goal any way other than being a CA.

grey-area 3 days ago | parent [-]

Sorry was not trying to be snarky, was interested in your answer as to what a better system would look like. The current one seems pretty broken but hard to fix.

Ajedi32 3 days ago | parent | prev | next [-]

In an ideal world where we rebuilt the whole stack from scratch, the DNS system would securely distribute key material alongside IP addresses and CAs wouldn't be needed. Most modern DNS alternatives (Handshake, Namecoin, etc) do exactly this, but it's very unlikely any of them will be usurping DNS anytime soon, and DNS's attempts to implement similar features have been thus far unsuccessful.

tptacek 3 days ago | parent [-]

People who idealize this kind of solution should remember that by overloading core Internet infrastructure (which is what name resolution is) with a PKI, they're dooming any realistic mechanism that could revoke trust in the infrastructure operators. You can't "distrust" .com. But the browsers could distrust Verisign, because Verisign had competitors, and customers could switch transparently. Browser root programs also used this leverage to establish transparency logs (though: some hypothetical blockchain name thingy could give you that automatically, I guess; forget about it with the real DNS though).

ysleepy 3 days ago | parent | next [-]

.com can issue arbitrary certificates right now, they control what DNS info is given to the CAs. So I don't quite see the change apart from people not talking about that threat vector atm.

tptacek 3 days ago | parent [-]

Get one to issue a Google.com certificate and see what happens.

xorcist 2 days ago | parent | next [-]

This is a bad faith argument. Whatever measures Google takes to prevent this (certificate logs and key pinning) could just as well be utilized if registrars delegated cryptographic trust as they delegate domains.

It is also true that these contemporary prevention methods only help the largest companies which can afford to do things like distributing key material with end user software. It does not help you and me (unless you have outsourced your security to Google already, in which case there is the obvious second hand benefit). Registrars could absolutely help a much wider use of these preventions.

There is no technical reason we don't have this, but this is one area where the interest of largest companies with huge influence over standards and security companies with important agencies as customers all align, so the status quo is very slow to change. If you squint you can see traces of this discussion all the way from IPng to TLS extensions, but right now there is no momentum for change.

tptacek 2 days ago | parent [-]

It's easy to tell stories about shadowy corporate actors retarding security on the Internet, but the truth is just that a lot of the ideas people have about doing security at global Internet scale just don't pan out. You can look across this thread to see all the "common sense" stuff people think should replace the WebPKI, most of which we know won't work.

Unfortunately, when you're working at global scale, you generally need to be well-capitalized, so it's big companies that get all the experience with what does and doesn't work. And then it's opinionated message board nerds like us that provide the narratives.

throwaway2037 3 days ago | parent | prev | next [-]

This is a great point. For all of the "technically correct" arguments going on here, this one is the most practical counterpoint. Yes, in theory, Verisign (now Symantec) could issue some insane wildcard Google.com cert and send the public-private key pair to you personally. In practice, this would never happen, because it is a corporation with rules and security policies that forbid it.

Thinking deeper about it: Verisign (now Symantec) must have some insanely good security, because every black hat nation state actor would love to break into on their cert issuance servers and export a bunch of legit signed certs to run man-in-the-middle attacks against major email providers. (I'm pretty sure this already happened in Netherlands.)

codethief 3 days ago | parent | next [-]

> every black hat nation state actor would love to break into on their cert issuance servers and export a bunch of legit signed certs to run man-in-the-middle attacks

I might be misremembering but I thought one insight from the Snowden documents was that a certain three-letter agency had already accomplished that?

9Ljdg6p8ZSzejt 2 days ago | parent [-]

This was DigiNotar. The breach generated around 50 certificates, including certificates for Google, Microsoft, MI6, the CIA, TOR, Mossad, Skype, Twitter, Facebook, Thawte, VeriSign, and Comodo.

Here is a nice writeup for that breach: https://www.securityweek.com/hacker-had-total-control-over-d...

9Ljdg6p8ZSzejt 2 days ago | parent [-]

Edits: I believe this is what you were referring to. It was around 500, not 50. Dropped a 0.

codethief 2 days ago | parent [-]

I do remember that breach but that was before Snowden. I'm relatively sure Snowden published some document about the NSA trying to undermine CAs, too.

Ajedi32 2 days ago | parent | prev | next [-]

This isn't about the cert issuance servers, but DNS servers. If you compromise DNS then just about any CA in the world will happily issue you a cert for the compromised domain, and nobody would even be able to blame them for that because they'd just be following the DNS validation process prescribed in the BRs.

tptacek 2 days ago | parent | prev [-]

Verisign (Symantec) can't do anything, because the browsers distrusted them.

ysleepy 2 days ago | parent | prev | next [-]

That only works for high profile domains, a CA can just issue a cert, log it to CT and if asked claim they got some DNS response from the authoritative server. Then it's a he said she said problem.

Or is DNSSEC required for DV issuance? If it is, then we already rely on a trustworthy TLD.

I'm not saying there isn't some benefit in the implicit key mgmt oversight of CAs, but as an alternative to DV certs, just putting a pubkey in dnssec seems like a low effort win.

It's been a long time since I've done much of this though, so take my gut feeling with a grain of salt.

tptacek 2 days ago | parent [-]

DNSSEC isn't required by anything, because almost nobody uses it.

Ajedi32 2 days ago | parent | prev [-]

Right. 'You can't "distrust" .com.' is probably not true in that situation. (If it were actually true, then "what happens" would be absolutely nothing.) I think you're undermining your own point.

transfire 3 days ago | parent | prev [-]

Who cares? What does a certificate tell me other than someone paid for a certificate.

And what do certificate buyers gain? The ability for their site to be revoked or expired and thus no longer work.

I’d like to corrected.

brazzy 3 days ago | parent | next [-]

Are you seriously not aware of Let's Encrypt? https://letsencrypt.org/

Nobody has really had to pay for certificates for quite a number of years.

What certificates get you, as both a website owner and user, is security against man-in-the-middle attacks, which would otherwise be quite trivial, and which would completely defeat the purpose of using encryption.

squiggleblaz 3 days ago | parent | prev [-]

A certificate authority is an organisation that pays good money to make sure that their internet connection is not being subjected to MITMs. They put vastly more resources into that than you can.

A certificate is evidence that the server you're connected to has a secret that was also possessed by the server that the certificate authority connected to. This means that whether or not you're subject to MITMs, at least you don't seem to be getting MITMed right now.

The importance of certificates is quite clear if you were around on the web in the last days before universal HTTPS became a thing. You would connect to the internet, and you would somehow notice that the ISP you're connected to had modified the website you're accessing.

Ajedi32 2 days ago | parent [-]

> pays good money to make sure that their internet connection is not being subjected to MITMs

Is that actually true? I mean, obviously CAs aren't validating DNS challenges over coffee shop Wi-Fi so it's probably less likely to be MITMd than your laptop, but I don't think the BRs require any special precautions to assure that the CA's ISP isn't being MITMd, do they?

JackSlateur 3 days ago | parent | prev | next [-]

No they should not

DANE is the way (https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...)

But no browser have support for it, so .. :/

talideon 2 days ago | parent [-]

Much as I like the idea of DANE, it solves nothing by itself and you need to sign the zone from tampering. Right now, the dominant way to do that is DNSSEC, though DNSCurve is a possible alternative, even if it doesn't solve the exact same problem. For DANE to be useful, you'd first need to get that set up on the domain in question, and the effort to get that working is far, far from trivial, and even then, the process is so error prone and brittle that you can easily end up making a whole zone unusable.

Further, all you've done is replace one authority (the CA authority) with another one (the zone authority, and thus your domain registrar and the domain registry).

JackSlateur 2 days ago | parent [-]

The zone authority already superseeds the CA authority in all ways

When I manage a DNS zone, I'm free to generate all certificates I want

throwaway2037 3 days ago | parent | prev | next [-]

This is a great question. If we don't have CAs, how do we know if it OK to trust a cert?

Are there any reasonable alternatives to CAs in a modern world? I have never heard any good proposals.

2 days ago | parent | next [-]
[deleted]
kbolino 2 days ago | parent | prev [-]

There are some alternatives.

Certificate pinning is probably the most widely known way to get a certificate out there without relying on live PKI. However, certificate pinning just shifts the burden of trust from runtime to install time, and puts an expiration date on every build of the program. It also doesn't work for any software that is meant to access more than a small handful of pre-determined sites.

Web-of-trust is a theoretical possibility, and is used for PGP-signed e-mail, but it's also a total mess that doesn't scale. Heck, the best way to check the PGP keys for a lot of signed mail is to go to an HTTPS website and thus rely on the CAs.

DNSSEC could be the basis for a CA-free world, but it hasn't achieved wide use. Also, if used in this way, it would just shift the burden of trust from CAs to DNS operators, and I'm not sure people really like those much better.

thayne 3 days ago | parent | prev | next [-]

In an ideal world we could just trust people not to be malicious, and there wouldn't be any need to encrypt traffic at all.

WJW 3 days ago | parent | prev | next [-]

How relevant is that since we don't live in such a world? Unless you have a way to get to to such a world, of course, but even then CAs would need to keep existing until you've managed to bring the ideal world about. It would be a mistake to abolish them first and only then start on idealizing the world.

klysm 3 days ago | parent | prev | next [-]

CAs exist on the intersection of reality (far from ideal) and cryptography.

Stefan-H 3 days ago | parent | prev [-]

What alternatives come to mind when asking that question? Not being in the PKI world directly, web of trust is what comes to mind, but I'm curious what your question hints at.

grey-area 3 days ago | parent [-]

I honestly don’t know enough about it to have an opinion, have vague thoughts that dns is the weak point anyway for identity so can’t certs just live there instead but I’m sure there are reasons (historical and practical).