4 ms·

> At this time, we believe that the issue can be addressed by having certain services providers implement stronger controls for domains hosted on their infrastr

> At this time, we believe that the issue can be addressed by having certain services providers implement stronger controls for domains hosted on their infrastructure. Requiring unrelated third-parties to take specific action(s) to prevent Let's Encrypt from incorrectly issuing certificates doesn't sound like a valid solution to this issue. What about the shared hosting providers that are "affected" that decide to do nothing to "fix" this?

ZiiS 9y ago
Slightly mitigated by only effecting the domains of people who chose to use such a hosting provider; but I agree this doesn't seem to meet the bar we should expect from a CA.
jmhodges 9y ago
There are equivalent attacks on both the DNS and HTTP challenges as described in the Baseline Requirements and ACME, and those are expected to be mitigated (and are) by hosting providers. Let's Encrypt isn't bound by the Baseline Requirements to mitigate this for these hosting providers, but is doing so out of a esprit-de-corps while the web figures out how it wants to handle this. Hosting providers haven't, previously, thought of TLS serving as an individual user service before (though the Baseline Requirements do) and are having to work out the kinks of that.
- jo909 9y ago
  I don't think they are really equivalent. We are talking about Domain Validated Certificates, and for DNS and HTTP "attacks" you need to be able to serve content in the name/as part of that domain. In this attack you need to be able to serve content in the "name of" a made up TLS name under an IP you share with the domain you attack (which is very common).
  - jmhodges 9y ago
    My "Hosting providers haven't, previously, thought of TLS serving as an individual user service before (though the Baseline Requirements do) and are having to work out the kinks of that." covers what you're trying to get at here.
    - jo909 9y ago
      I agree completely with that sentence factually and as an explanation why we have such issues, but still think HTTP and DNS are fundamentally different to this issue with the TLS-SNI challenge. The domain under attack is not part of the actual challenge process here. As a hosting provider I never see it and it plays no role in the decision of what information I reply with. At no point do I serve content under the "wrong" domain. At no point does the attacker show any control over the domain being validated.
      - jmhodges 9y ago
        Well, no, the DNS resolved to these endpoints, just like in an HTTP attack, and then this is as if the Host header wasn't checked by the HTTP provider. You and these few specific hosting providers didn't think they had to look at the SANs, but, in fact, the Baseline Requirements expected them to verify that the SANs in the certs are controlled by the same user. There's a reasonable disagreement but I (and others[1]) liken this the "postmaster@" attacks. At some point, for every protocol the hosting provider handles, we always end up having them do a bit more work then they thought they had to do but them's the breaks when dealing with the modern internet. [1] https://twitter.com/sleevi_/status/951041801368035328 https://twitter.com/sleevi_/status/951041801368035328
        jo909 9y ago
        I don't advocate for such hosting providers to not mitigate that attack. It's a real problem and needs a real solution, no matter the technical or political reasons that lead to this. Those hosting providers might not ever want to use LE for their customers and might arguably not be "at fault", but still their customers are at risk and they should take steps to protect them. But I still think it's a different problem in this case. In the end I suppose my argument is that this is a design flaw in this challenge and we ideally should not use it in it's current form, just as we no longer should use postmaster@ for domain validation (but the technical argument against postmaster@ is again a fundamentally different one). Edit: I realized I was wrong and removed one part of my response regarding IP lookup as a positive sign of domain ownership.
  - fomojola 9y ago
    Very curious what the DNS attack would look like: as far as I use it you need to be able to create arbitrary TXT records for the domain in question. Given that you won't be able to create TXT records for a domain you don't have control over (e.g. example.com) I can't quite figure out what the attack would look like?
tialaramex 9y ago
In specific answer to your second question, Let's Encrypt intends to blacklist IPs for those providers from using tls-sni-01 proof of control. Now, requiring unrelated third-parties to take action is (perhaps unfortunately) nothing new for DV. Back in the day lots of the web mail providers got bitten because some CA would decide that, say, receipt of email to ssl-certificate-officer@example.com is proof of control of example.com, so you just sign up for web mail and say you want the email address ssl-certificate-officer and bingo you get a certificate for a few bucks. This was exploited over and over. Even today, the Ten Blessed Methods let a CA choose any email address you listed in WHOIS (fair enough, don't list anybody else's address in WHOIS) _or_ any of 'admin', 'administrator', 'webmaster', 'hostmaster', or 'postmaster'. So when you build a web mail system you need to explicitly blacklist those five email addresses even if you would never need an account named "webmaster" or "admin", if you fail to take this specific action anybody can get certificates for your domain by talking to any of the commercial CAs that use a method complying with 3.2.2.4.4. Let's Encrypt already disabled a feature of http-01 validation before going live to avoid needing bulk web hosts and CDNs to make a sensible configuration choice, because surveys suggested that lots of them had left insecure default choices enabled. Or another email example (again thus not affecting Let's Encrypt): Lots of companies purchased anti-phishing systems that scan all incoming email to check for dodgy links. These systems typically dereference all the links, check what they find and quarantine suspicious emails. Several CAs had systems which sent an email saying "Just click here to authorize issuance". The anti-phishing system follows the link, now it's clicked, anyone could get a certificate for these domains because the anti-phishing system would "authorize" anything they requested... Now, all these are historical rather than current examples, but they do illustrate that "requiring unrelated parties to take specific actions" won't be new or unique to Let's Encrypt.
- teddyh 9y ago
  > So when you build a web mail system you need to explicitly blacklist those five email addresses… Actually, you should blacklist all of the addresses listed in RFC 2142¹. Also consider this blog post for additional addresses to block: https://ldpreload.com/blog/names-to-reserve https://ldpreload.com/blog/names-to-reserve 1. https://tools.ietf.org/html/rfc2142 https://tools.ietf.org/html/rfc2142
y0ghur7_xxx 9y ago
> What about the shared hosting providers that are "affected" that decide to do nothing to "fix" this? The problem is that I can upload a self signed certificate on a shared host for a domain I don't own. This, in and for itself, should not be a problem. I did nothing wrong, and the shared host did nothing wrong as well: it only allowed me to upload a self signed cert for an inexistent domain. IMHO, those two actions should not allow someone to get a valid cert for a domain they don't control, and whose only fault is that they pointed their A record to the shared domain host. I don't think TLS-SNI is sufficient proof of Domain Control. IMHO it should be sacked.
- lathiat 9y ago
  As someone with a long history in shared hosting, I have to agree. Basically requesting that ".acme.invalid" SNI proves ownership only of the ".acme.invalid" name and not the actual domain name in any way. I don't see any way this scheme can work. The only way I can see this working is having to pre-install a self-signed certificate with the same private key as the requested certificate to sign, on the actual domain name. I think that can work, can't it? I'd have to try it with openssl.. They may be able to fix it for larger providers but you'll forever have many smaller providers that will never mitigate the issue. The obvious problem with that is temporarily killing the real SSL certificate during initial setup. Though in theory they could re-use the private key.
- Ajedi32 9y ago
  > the shared host did nothing wrong as well I'm not so sure about that. Is it really a good idea to let customers configure security settings (e.g. the TLS cert used) for domains they don't own? I suppose as long as they're only doing it for invalid domains it shouldn't be an issue, but what if a customer were to set a cert for sitea.example (which they don't own) and then later the real owner of sitea.example comes along and wants to set up their site on the same host? Just doesn't seem like good practice to me. Maybe the solution here is to make the domain name sent by the SNI challenge a subdomain of the domain being validated? If a shared hosting site allows customers to set TLS certs for subdomains of a _completely different customer's_ domain name, that's most definitely a security issue regardless of whether or not TLS-SNI validation exists.

ZiiS 9y ago

Slightly mitigated by only effecting the domains of people who chose to use such a hosting provider; but I agree this doesn't seem to meet the bar we should expect from a CA.

jmhodges 9y ago

There are equivalent attacks on both the DNS and HTTP challenges as described in the Baseline Requirements and ACME, and those are expected to be mitigated (and are) by hosting providers. Let's Encrypt isn't bound by the Baseline Requirements to mitigate this for these hosting providers, but is doing so out of a esprit-de-corps while the web figures out how it wants to handle this. Hosting providers haven't, previously, thought of TLS serving as an individual user service before (though the Baseline Requirements do) and are having to work out the kinks of that.

jo909 9y ago
I don't think they are really equivalent. We are talking about Domain Validated Certificates, and for DNS and HTTP "attacks" you need to be able to serve content in the name/as part of that domain. In this attack you need to be able to serve content in the "name of" a made up TLS name under an IP you share with the domain you attack (which is very common).
- jmhodges 9y ago
  My "Hosting providers haven't, previously, thought of TLS serving as an individual user service before (though the Baseline Requirements do) and are having to work out the kinks of that." covers what you're trying to get at here.
  - jo909 9y ago
    I agree completely with that sentence factually and as an explanation why we have such issues, but still think HTTP and DNS are fundamentally different to this issue with the TLS-SNI challenge. The domain under attack is not part of the actual challenge process here. As a hosting provider I never see it and it plays no role in the decision of what information I reply with. At no point do I serve content under the "wrong" domain. At no point does the attacker show any control over the domain being validated.
    - jmhodges 9y ago
      Well, no, the DNS resolved to these endpoints, just like in an HTTP attack, and then this is as if the Host header wasn't checked by the HTTP provider. You and these few specific hosting providers didn't think they had to look at the SANs, but, in fact, the Baseline Requirements expected them to verify that the SANs in the certs are controlled by the same user. There's a reasonable disagreement but I (and others[1]) liken this the "postmaster@" attacks. At some point, for every protocol the hosting provider handles, we always end up having them do a bit more work then they thought they had to do but them's the breaks when dealing with the modern internet. [1] https://twitter.com/sleevi_/status/951041801368035328 https://twitter.com/sleevi_/status/951041801368035328
      - jo909 9y ago
        I don't advocate for such hosting providers to not mitigate that attack. It's a real problem and needs a real solution, no matter the technical or political reasons that lead to this. Those hosting providers might not ever want to use LE for their customers and might arguably not be "at fault", but still their customers are at risk and they should take steps to protect them. But I still think it's a different problem in this case. In the end I suppose my argument is that this is a design flaw in this challenge and we ideally should not use it in it's current form, just as we no longer should use postmaster@ for domain validation (but the technical argument against postmaster@ is again a fundamentally different one). Edit: I realized I was wrong and removed one part of my response regarding IP lookup as a positive sign of domain ownership.
- fomojola 9y ago
  Very curious what the DNS attack would look like: as far as I use it you need to be able to create arbitrary TXT records for the domain in question. Given that you won't be able to create TXT records for a domain you don't have control over (e.g. example.com) I can't quite figure out what the attack would look like?

tialaramex 9y ago

In specific answer to your second question, Let's Encrypt intends to blacklist IPs for those providers from using tls-sni-01 proof of control. Now, requiring unrelated third-parties to take action is (perhaps unfortunately) nothing new for DV. Back in the day lots of the web mail providers got bitten because some CA would decide that, say, receipt of email to ssl-certificate-officer@example.com is proof of control of example.com, so you just sign up for web mail and say you want the email address ssl-certificate-officer and bingo you get a certificate for a few bucks. This was exploited over and over. Even today, the Ten Blessed Methods let a CA choose any email address you listed in WHOIS (fair enough, don't list anybody else's address in WHOIS) _or_ any of 'admin', 'administrator', 'webmaster', 'hostmaster', or 'postmaster'. So when you build a web mail system you need to explicitly blacklist those five email addresses even if you would never need an account named "webmaster" or "admin", if you fail to take this specific action anybody can get certificates for your domain by talking to any of the commercial CAs that use a method complying with 3.2.2.4.4. Let's Encrypt already disabled a feature of http-01 validation before going live to avoid needing bulk web hosts and CDNs to make a sensible configuration choice, because surveys suggested that lots of them had left insecure default choices enabled. Or another email example (again thus not affecting Let's Encrypt): Lots of companies purchased anti-phishing systems that scan all incoming email to check for dodgy links. These systems typically dereference all the links, check what they find and quarantine suspicious emails. Several CAs had systems which sent an email saying "Just click here to authorize issuance". The anti-phishing system follows the link, now it's clicked, anyone could get a certificate for these domains because the anti-phishing system would "authorize" anything they requested... Now, all these are historical rather than current examples, but they do illustrate that "requiring unrelated parties to take specific actions" won't be new or unique to Let's Encrypt.

teddyh 9y ago
> So when you build a web mail system you need to explicitly blacklist those five email addresses… Actually, you should blacklist all of the addresses listed in RFC 2142¹. Also consider this blog post for additional addresses to block: https://ldpreload.com/blog/names-to-reserve https://ldpreload.com/blog/names-to-reserve 1. https://tools.ietf.org/html/rfc2142 https://tools.ietf.org/html/rfc2142

y0ghur7_xxx 9y ago

> What about the shared hosting providers that are "affected" that decide to do nothing to "fix" this? The problem is that I can upload a self signed certificate on a shared host for a domain I don't own. This, in and for itself, should not be a problem. I did nothing wrong, and the shared host did nothing wrong as well: it only allowed me to upload a self signed cert for an inexistent domain. IMHO, those two actions should not allow someone to get a valid cert for a domain they don't control, and whose only fault is that they pointed their A record to the shared domain host. I don't think TLS-SNI is sufficient proof of Domain Control. IMHO it should be sacked.

lathiat 9y ago
As someone with a long history in shared hosting, I have to agree. Basically requesting that ".acme.invalid" SNI proves ownership only of the ".acme.invalid" name and not the actual domain name in any way. I don't see any way this scheme can work. The only way I can see this working is having to pre-install a self-signed certificate with the same private key as the requested certificate to sign, on the actual domain name. I think that can work, can't it? I'd have to try it with openssl.. They may be able to fix it for larger providers but you'll forever have many smaller providers that will never mitigate the issue. The obvious problem with that is temporarily killing the real SSL certificate during initial setup. Though in theory they could re-use the private key.
Ajedi32 9y ago
> the shared host did nothing wrong as well I'm not so sure about that. Is it really a good idea to let customers configure security settings (e.g. the TLS cert used) for domains they don't own? I suppose as long as they're only doing it for invalid domains it shouldn't be an issue, but what if a customer were to set a cert for sitea.example (which they don't own) and then later the real owner of sitea.example comes along and wants to set up their site on the same host? Just doesn't seem like good practice to me. Maybe the solution here is to make the domain name sent by the SNI challenge a subdomain of the domain being validated? If a shared hosting site allows customers to set TLS certs for subdomains of a _completely different customer's_ domain name, that's most definitely a security issue regardless of whether or not TLS-SNI validation exists.