18

I just started using Let's Encrypt. The http-01-challenge is simple enough:

Works like a charm. But how are they making sure that I am really the owner of example.com using an insecure http-connection?

Couldn't some admin in my data center (or at my ISP) just request a certificate and intercept the http-requests, Let's Enrypt sends to check the server's identity?

7
  • 1
    Note that this problem would go away entirely with adoption of DANE, which would also make CAs irrelevant & obsolete. – R.. GitHub STOP HELPING ICE Aug 25 '20 at 3:48
  • 2
    @R..GitHubSTOPHELPINGICE True, but relying on DNSSEC would essentially amount to transferring our trust from the CA's to the registrars (e.g. firms like GoDaddy), the TLD's (e.g. VeriSign), and the root (e.g. ICANN). I'm not sure we can trust these entities any more than we can trust the CA's. See Moxie Marlinspike's blog post for an excellent write-up on this subject: thoughtcrime.org/blog/ssl-and-the-future-of-authenticity – mti2935 Aug 25 '20 at 8:40
  • 3
    @mti2935: "transferring our trust" <-- nope! This is a persistent fallacy. DNS and thus registrars are always in the chain of trust because they're the basis on which ownership of domain to obtain CA-signed certificates is evaluated. Using DANE is purely eliminating spurious risky parties in the chain, not adding any new ones. – R.. GitHub STOP HELPING ICE Aug 25 '20 at 15:20
  • 1
    @mti2935: "After that...it would be detected by the browser" <-- also nope. If they act nefariously, a new certificate can be obtained on that basis and used and the browser will have no idea. CT logging creates an audit trail to show the new certificate was issued, but only the domain owner can know that the issuance was unintentional; to the user it's indistinguishable from intentional change by domain owner. Fundamentally, the CA system has strictly more points you have to trust, and no advantages at all. You can't get around this, despite prevalence of entrenched fallacies. – R.. GitHub STOP HELPING ICE Aug 25 '20 at 16:22
  • 1
    One thing to note is that there is presently no equivalent of CT for DNSSEC+DANE. However, CT only works with CAs because you trust them to participate based on consequences if they're caught not participating. An equivalent of CT could be constructed for DNSSEC that's not based on trusting anyone to participate, just distributed probing root/TLD servers, because unlike contacting every webserver on the web, DNS actually scales. – R.. GitHub STOP HELPING ICE Aug 25 '20 at 16:26
40

Indeed, there is no infallible protection against a man-in-the-middle attack for the HTTP-01 challenge.
Someone who can intercept traffic between the Let's Encrypt validation nodes and your server CAN pass the challenge and get a cert issued. If they can pull off BGP trickery they may not necessarily even be in the middle in the normal sense.
This applies to the HTTP-01 challenge and for unsigned domains also the DNS-01 challenge.

It's worth noting that this problem is not unique to Lets Encrypt, the validation done by traditional CAs for DV certificates generally has this same problem; they typically offer HTTP, DNS and Email validation options, all of which are susceptible to a MITM attack.

What Let's Encrypt has done to mitigate the problem, is to run each validation from multiple test nodes in different data centers, requiring that all the test results agree in order to issue the certificate. (Which I suspect makes them less susceptible to this type of abuse than most of the traditional CAs.)
This at least reduces the scope of who might be in "the middle", as large parts of "the middle" will be different as viewed from the different test nodes.

This is all about the default behavior of automated domain-validation by Let's Encrypt (and CAs in general), but the domain owner has been given some additional control with the requirement that public CA's must check CAA records.

In order to actually take control, the domain owner can take these steps:

  1. DNSSEC-sign the zone to ensure that the CAA data is not tampered with
    (Also protects the challenge itself in the case of DNS-01)
  2. Add one or more CAA records to limit issuance of certificates
    (Particularly CAA records that do not only name the CA that is allowed to issue, but also which account with that CA that is allowed)

With a CAA record looking something like this:

example.com. IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12346789"

the problem is much reduced as an impostor cannot trivially initiate the challenge in the first place.

Pay special attention to the accounturi parameter in the CAA data, this is what makes the policy specific to the domain owner's account with the specified CA.
A CAA record that only specifies the CA but not an account, while valid, would be of limited help as such a policy still allows any other customer of that CA to request having certificates issued.

13
  • 1
    @jornane Would you care to elaborate? They should not be able to authenticate as the domain owner's Let's Encrypt account (as specified by the accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12346789 part of the CAA ) – Håkan Lindqvist Aug 27 '20 at 15:37
  • 1
    Aha, phone didn’t show account-id, I saw only CAA 0 issue “letsencrypt.org, in that case it works, but it looks confusing when viewing your answer on a phone. Maybe you can add some wrapping? – jornane Aug 27 '20 at 15:49
  • 1
    @jornane I added a note clarifying the importance of accounturi. I had trouble finding a good compromise between somehow reducing the width and keeping it clear what the actual record data should look like. Hope this helps. – Håkan Lindqvist Aug 27 '20 at 16:58
  • 1
    @user1748155 1) I would say so for the signed case 2) DNSSEC provides signed proof that the exact set of records returned exists or that the requested records do not exist, if a mitm strips/changes something the tampering will be detected by a validating resolver 3) Something like that, I suppose. Also the DNS-01 challenge if unsigned 4) Client applications do not and cannot reliably do so as the CAA must match at the time of cert issuance but not afterwards. The auditing capability of Certificate Transparency logs is an actual tool we have to keep them honest (see eg crt.sh) – Håkan Lindqvist Jan 2 at 12:00
  • 1
    @user1748155 1) I can't answer regarding their phrasing, but I imagine that comes down to HTTP-01 being a bit easier for the user (and maybe giving a better first impression of the LE experience) rather than anything else 4) CAA was introduced for the purpose of defining a policy for who is allowed to issue, while DANE is more like what you were asking for (a policy regarding which cert should be presented by a service). Traditional CA's are obviously not at all keen on undermining their business model, so they are generally negative towards any suggested change in this regard in the CAB forum – Håkan Lindqvist Jan 2 at 17:39
9

Justification for using http when getting the HTTP-01 challenge is in the spec:

Because many web servers allocate a default HTTPS virtual host to a particular low-privilege tenant user in a subtle and non-intuitive manner, the challenge must be completed over HTTP, not HTTPS.

This challenge is distinct from the ACME protocol messages. The spec mandates https. ACME also has integrity and replay protections on its signed messages. Even if the traffic was captured, there is more to compromising it than just the unencrypted challenge. Of course there is some risk to it, but what's the alternative for a better domain verification procedure?


A more complete approach to monitoring for unauthorized certificates may involve certificate transparency. Search or set up alerts on CT logs for your names. Issuing CA, serial number, and date should all be familiar.

1
  • 3
    What you say about the ACME protocol messages being protected is true. However, I don't think the concern voiced in the question really seems to be about legitimate ACME requests being captured/tampered with/replayed, but rather a more straightforward scenario where the attacker has registered normally (anyone can register a new account), then requested the issuance of a certificate for the target domain name normally (any registered user can do this), then only having to use their MITM position for serving the challenge data. – Håkan Lindqvist Aug 24 '20 at 21:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.