4 ms·

This makes me wonder about the feasibility of performing an attack by * man-in-the-middling Let's Encrypt and a particular domain (or DNS, depending on the d

This makes me wonder about the feasibility of performing an attack by * man-in-the-middling Let's Encrypt and a particular domain (or DNS, depending on the domain validation challenge) * requesting a new certificate for that domain * spoofing the HTTP resource response (or DNS response, if applicable) I suppose this is mitigated by the way Let's Encrypt validates the agent software's public key on first use though, at least for websites that are currently using Let's Encrypt.

level3 6y ago
Let's Encrypt also mitigates this by validating from multiple vantage points, so a single man-in-the-middle is insufficient.
Denvercoder9 6y ago
> man-in-the-middling Let's Encrypt and a particular domain (or DNS, depending on the domain validation challenge) Let's Encrypt issues multiple verification requests from multiple servers in different locations, both physically and in the network topology. If you can MITM that, you've pretty much taken over the domain and the ability to get a certificate isn't the worst of the operators problems.
- marcosdumay 6y ago
  > and the ability to get a certificate isn't the worst of the operators problems That assumes a lot about the operators goals and values. It may very well be their worst problem. Eg. a journalist in a dictatorial area will very likely prefer not to have a cloud service than to upload his data into some compromised service. It's just that, if it is their worst problem, TLS is patently insufficient, so they must think about it when setting the system up.
tialaramex 6y ago
Yes, this could work, and has definitely been done, sometimes, against other public CAs. We found convincing evidence of this during work at one of my previous employers. But what tempers my concern over that finding is that we found this by looking at cases where there's clearly a DNS takeover - and actually it was rare to do certificate issuance. In most cases it seems if you can MitM say, an Arab's country's army headquarters group mail servers, you can just offer no encryption or serve a self-signed certificate and the users will accept that. So while the Ten Blessed Methods are, as expected, not enough in the face of a resourceful adversary (in this case perhaps the Mossad, NSA or similar) they're also a padlock on a fence with a huge gaping hole in it anyway, our first attention should be on fixing the hole in the fence.
renewiltord 6y ago
Usually lower energy to exploit the server running the ACME client or the infra around it than it is to subvert the Internet infra that surrounds the LE infra. For instance, you can subvert the internet infra around some ccTLD if you're that country pretty easily but then who really owns the domain? Probably you, the country, since you can do anything with the DNS and then anything with the traffic.
jcrawfordor 6y ago
While LE is indeed vulnerable to this kind of (difficult) attack, I wanted to make the point that LE still represents, for the most part, an improvement over the previous norms in the CA industry. ACME standardizes automated domain ownership validation to a relatively small number of options that have received relatively rigorous security review (leading to one being dropped due to security concerns, for example). In contrast, incumbent low-budget CAs have often been a bit of a wild west of automated validation methods, often based on email, that can and do fall to much simpler attacks than a large-scale on-path attack. While CA/B, Mozilla, and others have worked to improve on that situation by requiring CAs to implement more restrictive policies on how domains can be validated, ACME still represents a much better validated, higher-quality validation process than that offered by a number of major CAs for DV certificates. One approach to decentralized or at least compromised-CA-tolerant TLS is something called "perspectives" (also implemented as "convergence"). The basic concept is that it's a common attack for someone to intercept your traffic, but it's very difficult for someone to intercept many people's traffic on the internet. So, if the TLS certificate and key you receive from a website is the same as the one that many other people have received, it is most likely genuine. If it's different, that's an indicator of a potential on-path attack. This can be implemented by establishing trust between your computer and various "notaries" which basically just check the certificate from their perspective and confirm that it matches yours. I bring this up, because if you squint just right you can view ACME as being a method of bolting the same concept onto the existing CA infrastructure: before you connect to a website, LetsEncrypt acts as a notary by connecting to the domain from multiple perspectives and ensuring that the same person evidently controls it from all of them. While not perfect, this is a strong indicator that the person requesting the cert is legitimate. The on-path attack risk is almost, but not always, on a late stage of the network path to the user (e.g. their local network). The big weakness of the ACME approach is an interception of a late stage of the network path to the server. This tends to be much better secured, but hey, it's still something to worry about. There is obviously also a reliance on DNS, but I would say that DNS has basically always been the most critical single link in on-path attack protection.

level3 6y ago

Let's Encrypt also mitigates this by validating from multiple vantage points, so a single man-in-the-middle is insufficient.

Denvercoder9 6y ago

> man-in-the-middling Let's Encrypt and a particular domain (or DNS, depending on the domain validation challenge) Let's Encrypt issues multiple verification requests from multiple servers in different locations, both physically and in the network topology. If you can MITM that, you've pretty much taken over the domain and the ability to get a certificate isn't the worst of the operators problems.

marcosdumay 6y ago
> and the ability to get a certificate isn't the worst of the operators problems That assumes a lot about the operators goals and values. It may very well be their worst problem. Eg. a journalist in a dictatorial area will very likely prefer not to have a cloud service than to upload his data into some compromised service. It's just that, if it is their worst problem, TLS is patently insufficient, so they must think about it when setting the system up.

tialaramex 6y ago

Yes, this could work, and has definitely been done, sometimes, against other public CAs. We found convincing evidence of this during work at one of my previous employers. But what tempers my concern over that finding is that we found this by looking at cases where there's clearly a DNS takeover - and actually it was rare to do certificate issuance. In most cases it seems if you can MitM say, an Arab's country's army headquarters group mail servers, you can just offer no encryption or serve a self-signed certificate and the users will accept that. So while the Ten Blessed Methods are, as expected, not enough in the face of a resourceful adversary (in this case perhaps the Mossad, NSA or similar) they're also a padlock on a fence with a huge gaping hole in it anyway, our first attention should be on fixing the hole in the fence.

renewiltord 6y ago

Usually lower energy to exploit the server running the ACME client or the infra around it than it is to subvert the Internet infra that surrounds the LE infra. For instance, you can subvert the internet infra around some ccTLD if you're that country pretty easily but then who really owns the domain? Probably you, the country, since you can do anything with the DNS and then anything with the traffic.

jcrawfordor 6y ago

While LE is indeed vulnerable to this kind of (difficult) attack, I wanted to make the point that LE still represents, for the most part, an improvement over the previous norms in the CA industry. ACME standardizes automated domain ownership validation to a relatively small number of options that have received relatively rigorous security review (leading to one being dropped due to security concerns, for example). In contrast, incumbent low-budget CAs have often been a bit of a wild west of automated validation methods, often based on email, that can and do fall to much simpler attacks than a large-scale on-path attack. While CA/B, Mozilla, and others have worked to improve on that situation by requiring CAs to implement more restrictive policies on how domains can be validated, ACME still represents a much better validated, higher-quality validation process than that offered by a number of major CAs for DV certificates. One approach to decentralized or at least compromised-CA-tolerant TLS is something called "perspectives" (also implemented as "convergence"). The basic concept is that it's a common attack for someone to intercept your traffic, but it's very difficult for someone to intercept many people's traffic on the internet. So, if the TLS certificate and key you receive from a website is the same as the one that many other people have received, it is most likely genuine. If it's different, that's an indicator of a potential on-path attack. This can be implemented by establishing trust between your computer and various "notaries" which basically just check the certificate from their perspective and confirm that it matches yours. I bring this up, because if you squint just right you can view ACME as being a method of bolting the same concept onto the existing CA infrastructure: before you connect to a website, LetsEncrypt acts as a notary by connecting to the domain from multiple perspectives and ensuring that the same person evidently controls it from all of them. While not perfect, this is a strong indicator that the person requesting the cert is legitimate. The on-path attack risk is almost, but not always, on a late stage of the network path to the user (e.g. their local network). The big weakness of the ACME approach is an interception of a late stage of the network path to the server. This tends to be much better secured, but hey, it's still something to worry about. There is obviously also a reliance on DNS, but I would say that DNS has basically always been the most critical single link in on-path attack protection.