On Thu, Jan 11, 2018 at 4:50 PM, Doug Beattie via dev-security-policy < 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> 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
