HACKER Q&A
📣 anderspitman

What does LetsEncrypt prove that a public key in a DNS record doesn't?


As I understand it, the ACME protocol used by services like LetsEncrypt simply proves you control a domain. But to my rather security-naive self, it seems like you could just put a TLS public key directly in a domain record, and have browsers read that. I'm confident there are good reasons this won't work, and I can even guess at a few, but I'm looking for good resources that explain the ins and outs of the security implications here.

  👤 arkadiyt Accepted Answer ✓
> As I understand it, the ACME protocol used by services like LetsEncrypt simply proves you control a domain

Yes, but note that this is true of all Certificate Authorities. There is nothing special about ACME here.

> it seems like you could just put a TLS public key directly in a domain record, and have browsers read that

Ignoring DoT/DoH, DNS records are sent in plaintext with no integrity checks - anyone on your network path can replace the public key response with one of their choosing, allowing them to MITM your connection. DNSSEC provides integrity of DNS responses, and if it were more widely adopted then people could set their certificates as DNS records - this is precisely what DANE [1] is. But, DNSSEC will never see wide adoption.

[1]: https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...

👤 dilyevsky
I’m not totally sure but I’m guessing the question is basically “why not skip the middleman CA and just trust whoever controls the domain directly?” and the reason is you can’t be sure if example.com is actually who it says it is bc DNS is easily spoofable (e.g by your isp or a local government). ACME works because the challenge is exchanged offband
👤 toast0
LetsEncrypt submits certificates to certificate transparency logs, so there's a record of what is issued.

I think CAs are supposed to verify domain control from multiple network locations (but then, I've verified domain control by clicking a link in email to whois contacts and/or postmaster, and I didn't need to do that more than once, so they didn't send email from multiple places, but that was a while ago; standards get harder over time.

👤 DarylZero
If you put the (unsigned) public key in the DNS, then a web client's DNS can be compromised to impersonate your site.

If you get the LetsEncrypt cert, then specifically LetsEncrypt's DNS client bot has to be compromised. Furthermore, it's not as easy as spoofing DNS; you also have to somehow obtain the matching token from the LE client<->server exchange.

Arguably, this is a tradeoff, rather than one being absolutely more secure than the other. The LE is one high value target that could be compromised once affecting many people.

In practice, it's the second one that's more secure.

DNSSEC+DANE really does beat LE securitywise, but then DNSSEC usually works over some non-automated registrar web admin panel.

👤 lesserknowndan
The short answer is that Lets Encrypt and other Certificate authorities distribute server certificates / private key pairs that are signed by a Certificate Authority who has a certificate in your web browser / operating system that can be used to verify that signature.

Google “chain of trust”.

You can effectively do what you suggested by generating a self-signed certificate for your web server, but visitors either won’t be able to access your site or will need to accept the risk of connecting depending on the browser they use.