5 ms·

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

• arkadiyt 5y ago
  > 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_Named_Entities https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...
  • anderspitman 5y ago
    So ACME assumes it's harder to trick a LetsEncrypt server than it is to trick a random browser?
    • tinus_hn 5y ago
      ACME is a protocol. LetsEncrypt has checks against popular high value domains (you can’t get a LetsEncrypt certificate for Google.com) and they check from multiple locations and they have to match. It really isn’t much different if you use a commercial CA except you have to pay.
      • anderspitman 5y ago
        > ACME is a protocol Yeah I know. Does the protocol not specify that the records must be checked from multiple locations? That would certainly add a lot of protection, but if it's not required...
        • tinus_hn 5y ago
          If LetsEncrypt does it anyway, what protection is added by it being required by the protocol?
    • toast0 5y ago
      I can fake DNS for all the clients that come onto my network. And I can drop packets to all the popular DoH services too. If your client hosts its own recursive DNS server that does DNSSEC (which is very rare) and the domain has DNSSEC enabled (which is also very rare), then I would be forced to deny service rather than fake DNS. If I were going to trick a LetsEncrypt server, I need to control their network somehow, and that's a lot harder. LetsEncrypt isn't likely to sign up for my transit services at all of their locations.
• toast0 5y ago
  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 5y ago
  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.
  • ratorx 5y ago
    Small correction: while it’s true that the client<->server exchange is secure, this doesn’t matter because ANY client can request a certificate for any DNS address. It is no extra security, because an attacker can just submit their own request for the same domain from a different client that they control. It only needs to be secure to prevent MITMing the token. The key to LE security is to check the record from a bunch of servers with diverse paths to the nameserver, so that any particular intermediate ISP cannot spoof the DNS/TCP to all of them. Ideally these paths would be direct, but that’s not feasible, since the requesting server could theoretically be hosted anywhere. I guess they are also more likely to implement the recommended DNS security extensions than a (likely) out-of-date resolver in a consumer router.
• dilyevsky 5y ago
  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
  • sreevisakh 5y ago
    Isn't DNSSEC supposed to solve the spoofing problem?
    • dilyevsky 5y ago
      Yes but then you still need a trusted third party for clients to trust it. Now you’re back to proving to that third party that you really do own the domain
  • tomjen3 5y ago
    But I can get a signed key using a DNS challenge.
    • dilyevsky 5y ago
      Yes but then you need to spoof it to the CA itself which is harder. They also publish every cert they sign in transparency logs so the owner can monitor for any funky business
• lesserknowndan 5y ago
  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.