4 ms·

>> Except, when this Domain Validation is performed, you don't have a certificate yet. That's why you're going through the process in the first place: to get a

>> Except, when this Domain Validation is performed, you don't have a certificate yet. That's why you're going through the process in the first place: to get a certificate. Which means that when the CA verifies that your domain is correctly hosting the challenge, it does so via ordinary, unencrypted HTTP... which can be trivially subject to man-in-the-middle attacks. This is not completely true. For HTTP challenge, yes its true. But for DNS Challenge its not. DNS Challenge requires the provisioning of a special DNS Text record. Assuming you are using an API with your DNS provider this can happen over HTTPS. (Indeed I can confidently say it would Have to be over HTTPS, or similar.)

nmadden 4y ago
> For HTTP challenge, yes its true. I know very little about ACME, but surely this (not having a cert yet) is only true the very first time you get a cert, or if you let the existing cert expire?
- bruce511 4y ago
  Alas no. The http challenge method is http,regardless of whether you have an existing cert or not. However the protocol consists of a number of steps. Around 8 to 10 steps. For all but 1 of the steps you are the client connection, so these happen over https. So its not like the whole conversation is in the clear. The only step where the content is retrieved from the server is LE fetching a file, which is itself encrypted. So not over TLS, but the content itself is encrypted. So I'm not really sure how an MITM attack works here.
  - nmadden 4y ago
    As I understand it, the MITM attack is relying on the lack of authentication rather than lack of confidentiality. The attacker can go to LE and get a challenge file (AIUI), which they host on a fake version of the website. They then use DNS spoofing/cache poisoning/ARP spoofing/whatever to get the CA to hit their spoof website rather than the real one. This “proves” the attacker owns that domain and so they can then carry out the rest of the steps to get a cert. IMO its much harder to carry out this MITM against a CA compared to typical MITM attacks against end users. CAs generally speaking aren’t connecting to random wifi hotspots or using random ISPs etc. So you’d need to be in a pretty privileged network position to carry this out. And the multi-endpoint resolution approach seems like it would make it very hard indeed to pull off. That said, it seems a bit of a shame not to use the existing cert where one exists (which is presumably the case for most requests, which I’d expect are renewals).
bruce511 4y ago
And thinking further, I'm not sure how MITM attacks would be useful, or expose anything. They would see the challenge request itself go by, but that's all. Setting up the challenge, and fetching the certificate is done over https (the server acting as a client to LE.) I suppose the MITM machine could recognizes the challenge, and attempt to then fetch the valid certificate (first?). I don't recall offhand if the client has a nonce for that request, I'd have to go and review the spec.
- schoen 4y ago
  The MiTM allows the attacker to itself request and receive a certificate. You're right that it doesn't allow the attacker to tamper with (other than to block) the legitimate site's own attempt to receive certificates, but the legitimate site also can't block the attacker from completing the validation process.
3np 4y ago
Usually you still have CA -> DNS server being subject to MitM, unless you enforce DNSSEC.
hlandau 4y ago
Author here. A DNS challenge is equally vulnerable to MITM unless DNSSEC is used. The whole point here is that an entity which wants to MitM connections between a browser and website can obtain a certificate if they can MitM connections between a CA's validator and that website. If that validation isn't cryptographically secured, it's moot whether it uses HTTP or DNS from a security perspective.
mike_d 4y ago
> For HTTP challenge, yes its true. But for DNS Challenge its not. The query from LetsEncrypt to your authoritative DNS server is unencrypted. The method you use to make an update is irrelevant, since the response can be spoofed by a third party with backbone surveillance capabilities.
- cyphar 4y ago
  In that case, CAA doesn't help either because that record could also be faked. The answer of course is that you need DNSSEC in order for this to work, in which case the DNS challenge is already secure against spoofing without the need for this particular CAA extension. It doesn't hurt to have this feature, but I suspect it would primarily protect against misconfigured DNS (where there's a CNAME someone forgot to remove that points to a hosting provider an attacker can get an account on). And of course, for making the HTTP challenge more secure.
  - tialaramex 4y ago
    > but you could restrict the challenge type before IIRC I don't think so, that's what the other change Let's Encrypt announced does: The change mentioned actually lands two CAA attributes. All the below assumes DNS integrity, either via DNSSEC or because the attacker hasn't been able to spoof your DNS records for whatever reason. The accounturi attribute lets you bind to a specific ACME account, which means an attacker has to use your Let's Encrypt account to get certificates or it won't work. That means e.g. if you have a locked down ACME issuing server that has the account credentials and is supposed to handle all your issuing, but a bug means one of your test server got rooted by bad guys -- they don't get to issue certificates because they don't have the credentials from the locked down server. The validationmethods attribute lets you specify that only some ACME methods ("challenge types") are permissible for this CA. So you can rule out methods you don't use, and thus forbid them to an adversary who might have found a way to use them. If you have DNS integrity, set CAA to letsencrypt and validationmethods to require DNS ACME verification, you only need to protect DNS records, all your application protocol stuff is unable to cause issuance. So even though your new guy's "really cool" Python web service was immediately turned into a reverse shell by a Russian teenager and is now trying to send fake Viagra spam via your company email server, it can't get itself any certificates it wasn't supposed to have, which is a small blessing.
thayne 4y ago
In addition to the other points in sibling comments, even if you use DNS for your domain validation, and use DNSSEC, there is nothing to stop a MiTM attacker from requesting a certificate from Let's Encrypt (or some other CA) using the http method.
Dagger2 4y ago
It shouldn't need HTTPS -- DNS itself supports cryptographically signed updates.

nmadden 4y ago

> For HTTP challenge, yes its true. I know very little about ACME, but surely this (not having a cert yet) is only true the very first time you get a cert, or if you let the existing cert expire?

bruce511 4y ago
Alas no. The http challenge method is http,regardless of whether you have an existing cert or not. However the protocol consists of a number of steps. Around 8 to 10 steps. For all but 1 of the steps you are the client connection, so these happen over https. So its not like the whole conversation is in the clear. The only step where the content is retrieved from the server is LE fetching a file, which is itself encrypted. So not over TLS, but the content itself is encrypted. So I'm not really sure how an MITM attack works here.
- nmadden 4y ago
  As I understand it, the MITM attack is relying on the lack of authentication rather than lack of confidentiality. The attacker can go to LE and get a challenge file (AIUI), which they host on a fake version of the website. They then use DNS spoofing/cache poisoning/ARP spoofing/whatever to get the CA to hit their spoof website rather than the real one. This “proves” the attacker owns that domain and so they can then carry out the rest of the steps to get a cert. IMO its much harder to carry out this MITM against a CA compared to typical MITM attacks against end users. CAs generally speaking aren’t connecting to random wifi hotspots or using random ISPs etc. So you’d need to be in a pretty privileged network position to carry this out. And the multi-endpoint resolution approach seems like it would make it very hard indeed to pull off. That said, it seems a bit of a shame not to use the existing cert where one exists (which is presumably the case for most requests, which I’d expect are renewals).

bruce511 4y ago

And thinking further, I'm not sure how MITM attacks would be useful, or expose anything. They would see the challenge request itself go by, but that's all. Setting up the challenge, and fetching the certificate is done over https (the server acting as a client to LE.) I suppose the MITM machine could recognizes the challenge, and attempt to then fetch the valid certificate (first?). I don't recall offhand if the client has a nonce for that request, I'd have to go and review the spec.

schoen 4y ago
The MiTM allows the attacker to itself request and receive a certificate. You're right that it doesn't allow the attacker to tamper with (other than to block) the legitimate site's own attempt to receive certificates, but the legitimate site also can't block the attacker from completing the validation process.

3np 4y ago

Usually you still have CA -> DNS server being subject to MitM, unless you enforce DNSSEC.

hlandau 4y ago

Author here. A DNS challenge is equally vulnerable to MITM unless DNSSEC is used. The whole point here is that an entity which wants to MitM connections between a browser and website can obtain a certificate if they can MitM connections between a CA's validator and that website. If that validation isn't cryptographically secured, it's moot whether it uses HTTP or DNS from a security perspective.

mike_d 4y ago

> For HTTP challenge, yes its true. But for DNS Challenge its not. The query from LetsEncrypt to your authoritative DNS server is unencrypted. The method you use to make an update is irrelevant, since the response can be spoofed by a third party with backbone surveillance capabilities.

cyphar 4y ago
In that case, CAA doesn't help either because that record could also be faked. The answer of course is that you need DNSSEC in order for this to work, in which case the DNS challenge is already secure against spoofing without the need for this particular CAA extension. It doesn't hurt to have this feature, but I suspect it would primarily protect against misconfigured DNS (where there's a CNAME someone forgot to remove that points to a hosting provider an attacker can get an account on). And of course, for making the HTTP challenge more secure.
- tialaramex 4y ago
  > but you could restrict the challenge type before IIRC I don't think so, that's what the other change Let's Encrypt announced does: The change mentioned actually lands two CAA attributes. All the below assumes DNS integrity, either via DNSSEC or because the attacker hasn't been able to spoof your DNS records for whatever reason. The accounturi attribute lets you bind to a specific ACME account, which means an attacker has to use your Let's Encrypt account to get certificates or it won't work. That means e.g. if you have a locked down ACME issuing server that has the account credentials and is supposed to handle all your issuing, but a bug means one of your test server got rooted by bad guys -- they don't get to issue certificates because they don't have the credentials from the locked down server. The validationmethods attribute lets you specify that only some ACME methods ("challenge types") are permissible for this CA. So you can rule out methods you don't use, and thus forbid them to an adversary who might have found a way to use them. If you have DNS integrity, set CAA to letsencrypt and validationmethods to require DNS ACME verification, you only need to protect DNS records, all your application protocol stuff is unable to cause issuance. So even though your new guy's "really cool" Python web service was immediately turned into a reverse shell by a Russian teenager and is now trying to send fake Viagra spam via your company email server, it can't get itself any certificates it wasn't supposed to have, which is a small blessing.

thayne 4y ago

In addition to the other points in sibling comments, even if you use DNS for your domain validation, and use DNSSEC, there is nothing to stop a MiTM attacker from requesting a certificate from Let's Encrypt (or some other CA) using the http method.

Dagger2 4y ago

It shouldn't need HTTPS -- DNS itself supports cryptographically signed updates.