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?
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.
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
I'm curious what this was. Can you elaborate or point me somewhere I can read about that?
Now, suppose http://no-ssl.customer1.example/ is a site Customer 1 is running on a bulk host, and it doesn't have SSL. We (the attacker) ask Let's Encrypt for an HTTPS version of the http-01 validation for this name no-ssl.customer1.example
A DNS lookup of no-ssl.customer1.example gives Let's Encrypt the IP address of the bulk hosting server. They connect to port 443 of that address, and they do SNI and say they expect to talk to no-ssl.customer1.example, then they do an HTTP request with Host: no-ssl.customer1.example and a GET for the relevant .well-known/acme-challenge/ file - what happens?
A common default configuration of web servers used by bulk hosters says if anything doesn't match, let's use a "default" such as the first (often alphabetically first) named virtual host to serve the answers. No error, just assume that must be what the request was really for.
Since there is no SSL version of no-ssl.customer1.example, the server drops through to this default, and the web server offers the certificate and content for aaaaa.attacker.example which we, the attacker have prepared. This includes the ACME answer file, Let's Encrypt is satisfied we have "control" over no-ssl.customer1.example and grants us a certificate we clearly shouldn't have.
Apache and nginx both do this by default. Lots of bulk hosts are set up to use them without a configuration that prevents this happening, and they didn't seem to be in any hurry to fix it.
So, Let's Encrypt disabled this feature for their production release.
1. Isn't the default virtual host practice still a problem even without TLS/SNI? Apache chooses a default virtual host on port 80 in the same way. Is that "acceptable" simply because it's more common for the default port 80 virtual host to be controlled by the hosting provider? That's not as robust as one would hope.
2. Wouldn't http-01 over TLS be made safe if the certificate was required to be valid for the domain being challenged? Granted, there's a TLS chicken and egg problem there, but that's beside the point.
[0] https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-...
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.
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.
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.
FWIW, Matthew Hardeman just made an excelent post on the mozilla.dev.security.policy which discusses this solution and some potential problems with it in detail: https://groups.google.com/d/msg/mozilla.dev.security.policy/...
> So I don't think this buys any improvement over the status quo, and actually makes it considerably more complex and failure prone, due to the cross-sectional lookups, versus the fact that .invalid is a reserved TLD.
So it should be more likely for shared hosting services to recognize that .invalid is an explicitly reserved TLD, vs correctly walking subdomains and recognizing "effective TLDs" (which vary in number of dot-separated elements).
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.
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).
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.
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.
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.