Ryan, I’d like to follow up on our investigation and provide the community with some more information about how we use Method 9.
We use a process that we refer to as OneClick to automate the domain validation and issuance of certificates by issuing a test certificate to an FQDN and then verifying that the certificate is present on that FQDN. This is different from ACME method TLS-SNI-01, regardless of what some GlobalSign tweets may have mentioned. Where dedicated IP addresses are used, we believe this method is safe and secure. So, I’ll focus this discussion on when there are shared IP addresses and SNI is used. This is how the OneClick validation works: 1) Client requests a test certificate for a domain (only one FQDN) 2) We issue a test certificate valid for 7 days 3) Client places the test certificate on their server 4) We connect to the server (DNS look-up and then use SNI to ask for the certificate) 5) If the certificate is returned, the validation passes and we issue a production certificate which is downloaded and installed. The issued certificate can have validity up to 39 months (soon 825 days) For shared IP address environments, it may be possible to receive a certificate for a domain you don’t actually control, but a number of things need to happen in order for this to be successful. What can go wrong? 1) A user could request a test certificate for a domain they don’t own within a shared IP address environment. In order for this to be successful: a. User must know which other sites are hosted on the same IP address (the attack is limited to the set of customers on that shared IP address) b. For this case, I’m assuming that sites don’t have TLS enabled (if they did when we went to validate them, we’d receive their certificate – more on this below in case 2) c. The hosting company must allow you to manually create and upload a CSR for a site you don’t own 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 2) In the event that the target site does have TLS enabled and the attacker wants to override the account settings to provide this test certificate, they would need the provider to allow multiple accounts to claim the SNI traffic for that site. This scenario seems unlikely (and if they did, it would be generally insecure) Our typical hosting customers have integrated certificate provisioning into their account/service set-up so a certificate can be provisioned quickly and easily. Normally, there is no user involvement in key generation and the backend systems take care of this provisioning and would not allow test certificates to be uploaded other than for the purpose they are intended (to secure a specific site). In this case, we don’t believe that there is a security issue since the system would be creating and validating domains/certificates as expected. If users are able to initiate the domain validation process and if they are permitted to upload certificates for sites they don’t control, then there is a possibility that they could get a certificate for that domain. We can’t control what every provider does, so this risk remains. While the vulnerabilities and risks are different between ACME TLS-SNI-01 and OneClick, 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. If this is acceptable, we’d like to resume issuance today if possible. Doug From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Thursday, January 11, 2018 5:19 PM To: Doug Beattie <doug.beat...@globalsign.com> Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Possible Issue with Domain Validation Method 9 in a shared hosting environment On Thu, Jan 11, 2018 at 4:50 PM, Doug Beattie via dev-security-policy <dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>> wrote: Based on reported issues with TLS-SNI-01, we started investigation of our systems late yesterday regarding the use of "Test Certificate" validation, BR section 3.2.2.4.9. We found that this method may be vulnerable to the some of the same underlying issue as the ACME TLS-SNI-01 so we disabled it at 10:51 AM today EST, January 11th. While TLS-SNI-01 uses a host name like 773c7d.13445a.acme.invalid, GlobalSign uses the actual host name, www.example.com<http://www.example.com><http://www.example.com> which limits abuse, but we believe that the process might be vulnerable in some cases. We're continuing to research this and will let you know what we find. Doug (Wearing a Chrome Hat, again) Doug, Thanks for the update. That seems consistent with Chrome's evaluation, as shared at https://groups.google.com/d/msg/mozilla.dev.security.policy/RHsIInIjJA0/HACyY9tMAAAJ We'd like to ask that you work with the community and browsers on this prior to re-enabling this validation method, for the reasons outlined in that thread. In particular, unlike the ACME methods that are specified, it's unclear the validation process used by GlobalSign in applying 3.2.2.4.9. This makes it particularly more challenging to evaluate the potential risks and/or mitigations that may exist, and so sharing full and complete details about the method you use publicly can assist browsers and the broader community to evaluate and assess, much the same as TLS-SNI for ACME. Further, as called out in that other thread, there's a risk calculus based on the lifetime of the certificates issued that directly plays into whether or not the method can be re-enabled and for how long. We'd love to work with you to better understand these tradeoffs, as applied to .9, so that we can make informed decisions about the risk to sites and users. Thanks for your report, for disabling the validation, and for continued collaboration to best protect users. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
