Wayne, We didn’t really investigate wildcard issuance yet, but we can.
Given the discuss so far, we’re planning to proceed with a whitelisting approach tomorrow and we will plan to end the use of Method 9 (schedule TBD) which follows Let’s Encrypt handling of Method 10. If there are any additional security concerns that we need to be made aware of, please let me know and we can adjust the plan accordingly. Doug From: Wayne Thayer [mailto:wtha...@mozilla.com] Sent: Friday, January 12, 2018 3:43 PM To: Doug Beattie <doug.beat...@globalsign.com> Cc: Gervase Markham <g...@mozilla.org>; r...@sleevi.com; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Possible Issue with Domain Validation Method 9 in a shared hosting environment On Fri, Jan 12, 2018 at 11:21 AM, Doug Beattie <doug.beat...@globalsign.com<mailto:doug.beat...@globalsign.com>> wrote: Normally a web hosting provider should not let you set SNI for a domain someone else is using, especially on that IP address. I think this is where method 9 deviates from method 10. I agree, it seems somewhat less likely that a hosting provider would allow someone to create a site for abc.example.com<http://abc.example.com> if one already exists on the same server. Are you aware of any hosting providers that do allow this? Also, did you consider wildcard DNS records in your analysis of the vulnerability? (see below) For method 10, you set up SNI on your server and add the acme.invalid string associated with your request/cert. Since nobody owns that invalid domain, the provider probably doesn’t care that you set up that SNI name and are using a certificate for that fqdn on their shared IP address. It's also possible that the only thing the hosting provider checks is if there is already an SNI entry for that FQDN, in which case sites that aren't configured for TLS would be vulnerable. For method 10 we look explicitly for the FQDN in the cert and there is no special SNI reconfiguration required (the site is there before, during and after the validation and issuance). Are you confusing method 9 and method 10 in this sentence and the one below? Yes, Method 9. Do hosting providers allow you to set SNI for domains you don’t own on a shared IP addresses? I think that is exactly what has been found to be true. That sounds bad, but I defer to the experts here. Method 9 does not require that. Also, the ACME client actively support the process of allowing this random acme.invalid value to be tied to the real FQDN and looks for requests based on that SNI name. All of the OneClick plugins (which btw, support similar features like client like key generation, cert installation and apache configuration), require that the FQDN being validated match the value in the certificate and the SNI server name. Validation will fail when the SNI does not match what is expected. The vast majority of OneClick endpoints are not vulnerable (yes, bad guys can modify the plugins and subvert the security we built in). Yes, there is a vulnerability, but I think it’s a smaller scale than what’s in TLS-SNI-01. Do you perform wildcard certificate validation with this method? If so, could someone create a site for evil.example.com<http://evil.example.com> on the same server as www.example.com<http://www.example.com> and then get a cert for *.example.com<http://example.com> by relying on a wildcard DNS record in the example.com<http://example.com> zone (i.e. DNS responds to a query for evil.example.com<http://evil.example.com> with the IP for www.example.com<http://www.example.com>)? _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
