Wayne and Gerv, I’ll try to answer both of your questions here.
From: Wayne Thayer [mailto:wtha...@mozilla.com] Sent: Friday, January 12, 2018 11:03 AM To: Doug Beattie <doug.beat...@globalsign.com> Cc: r...@sleevi.com; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Possible Issue with Domain Validation Method 9 in a shared hosting environment Doug, I have some questions: c. The hosting company must allow you to manually create and upload a CSR for a site you don’t own Did you mean to say 'certificate' here instead of 'CSR'? Yes, I meant to say certificate. d. The user must be able to trick the hosting provider to enable SNI for this domain and link it to the certificate they uploaded Is 'trick' the right term here? Isn't this just a default configuration for vulnerable hosting providers? From Gerv: Doug: what do you see as the exact differences between your setup and the TLS-SNI-01 configuration? It seems to me that both are vulnerable in the same circumstances (i.e., hosting provider has many users hosted on the same IP address, and users have the ability to upload certificates for arbitrary names without proving domain control). 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. 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. 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). Do hosting providers allow you to set SNI for domains you don’t own on a shared IP addresses? 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. While the vulnerabilities and risks are different between ACME TLS-SNI-01 and OneClick, Can you explain this statement? My impression is that the same vulnerability affects both methods. Listed above. we’d like to propose a risk mitigation approach similar to Let’s Encrypt with the use of a whitelist. We’ll verify that certain providers have secure practices in place to prevent users from requesting certificates outside of their permitted domains and then whitelist them. Let's Encrypt has stated that this is a short- to medium-term mitigation. Is your plan to continue to use this method indefinitely? Or are you ultimately planning to fix or deprecate the method? If we’re required to deprecate this because of similar security concerns, we can do that. If this is acceptable, we’d like to resume issuance today if possible. If my understanding of the 3.2.2.4.9 vulnerability being essentially the same as the 3.2.2.4.10 vulnerability, then this seems reasonable to me, at least in the short term. Thanks Wayne. Wayne _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
