On Fri, Jan 12, 2018 at 11:21 AM, Doug Beattie <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 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? 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 on the same server as www.example.com and then get a cert for *.example.com by relying on a wildcard DNS record in the example.com zone (i.e. DNS responds to a query for evil.example.com with the IP for www.example.com)? > > > While the vulnerabilities and risks are different between ACME TLS-SNI-01 > and OneClick, > > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
