21

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?

Andreas
  • 393
  • 4
  • 11
  • 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 03: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: http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity – mti2935 Aug 25 '20 at 08:40
  • @mti2935 That link looks broken to me, try the following instead: https://moxie.org/2011/04/11/ssl-and-the-future-of-authenticity.html – TooTea Aug 25 '20 at 14:18
  • 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
  • @R..GitHubSTOPHELPINGICE, True. But, in the current CA model, the registrar, TLD, and root need only to be trusted for a short period of time when the CA is being requested and issued. After that, if the registrar, TLD, or root were to act nefariously and attempt an attack using a fake certificate, it would be detected by the browser. This is in contrast to the DNSSEC/DANE model, where these entities could act nefariously at any time, and replace the real certificate stored in DANE with a fake one, and it would go undetected. – mti2935 Aug 25 '20 at 16:08
  • 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

2 Answers2

41

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.

Håkan Lindqvist
  • 33,741
  • 5
  • 65
  • 90
  • Downvoting as CAA is not a mitigation for the stated problem; a third party can still request a rogue Let’s Encrypt certificate. – jornane Aug 27 '20 at 15:32
  • 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
  • @jornane (Alternatively, if the domain owner specifies a different CA altogether in the CAA, the attacker would not be able to use Let's Encrypt at all) – Håkan Lindqvist Aug 27 '20 at 15:40
  • 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
  • So, is the DNS-01 challenge with DNSSEC far superior to the HTTP-01 challenge then? Are there any holes in the DNS-01 challenge tying a domain to a certificate if the registrar is trusted and the domain owner's account with the registrar has not been compromised, and the certificate authority (in this case Let's Encrypt) is trustworthy? – user1748155 Jan 02 '21 at 03:01
  • Does DNSSEC by default indicate whether a CAA record exists or not? Just wondering if a man in the middle could omit a CAA record from a query and then the certificate authority (who you say must check CAA records) thinks one doesn't exist, but it really does. – user1748155 Jan 02 '21 at 03:05
  • Since you say the HTTP-01 challenge used by Let's Encrypt, as well as HTTP, DNS, and email based validation options that traditional CA's use, all suffer from this same potential for a man in the middle attack, could we say that they all have a "trust at this moment in time" model, similar to a "trust on first use" model? – user1748155 Jan 02 '21 at 03:13
  • You say that public CA's must check CAA records before issuing a certificate. Do web browsers, e-mail clients, etc. also check CAA records to make sure that the CA's are being honest? – user1748155 Jan 02 '21 at 03:15
  • 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 https://crt.sh/) – Håkan Lindqvist Jan 02 '21 at 12:00
  • (1) OK, seems weird because Let's Encrypt "appears" based on their word choices to be promoting the HTTP-01 challenge as the primary and DNS-01 as a fallback. (2) OK. (3) OK. (4) Interesting, I guess you may want to revoke your certificate if you change your CAA record. Seems like a round about way to do verification with the Transparency Logs. Not sure why https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities has not taken off, as it seems to avoid the need for CA's entirely. Thanks for all your help. – user1748155 Jan 02 '21 at 17:11
  • 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 02 '21 at 17:39
  • 1
    @user1748155 As for CT getting traction but DANE not so much (other than in specific use-cases), I think that one basically comes down to CT being a minimal change to the existing ecosystem; it pretty much maintains the status-quo but adds auditing capabilities. "Users" are essentially unaffected, and no one is getting their business model killed off. I suppose that all makes it comparatively trivial to introduce CT, while for instance DANE is trickier both in terms of the work required by "users" to transition there and how the CAs obviously despise the very idea. – Håkan Lindqvist Jan 02 '21 at 18:20
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.

Community
  • 1
John Mahowald
  • 30,009
  • 1
  • 17
  • 32
  • 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