On Tue, Jan 16, 2018 at 3:31 PM, Doug Beattie <[email protected]> wrote:
> Ryan, > > > > Here is some more information to continue the discussion. > > - We will continue to post all certificates to CT logs so > issuance can be monitored. > > - We will reduce validity period of OneClick certificates to 6 > months. > > - We will work with the hosting providers (on a case by case > basis) to implement processes and procedures which prevent the uploading > and use of test certificates on user controlled shared IP addresses > (similar to how LE worked with their larger customers to blocking > acme.invalid from being used) > > > Hi Doug, For the reasons explained below, this set of proposed mitigations aren't equivalent, and unfortunately don't meet the necessary level. Hopefully, by pointing to past discussion with additional details, it may inspire additional ideas to meet that mitigation. Certainly, on the validity period, there's not much opportunity to budge here, given our risk assessment to the ecosystem and our users. > More below. > > > > *From:* Ryan Sleevi [mailto:[email protected]] > *Sent:* Monday, January 15, 2018 4:56 PM > *To:* Doug Beattie <[email protected]> > *Cc:* [email protected]; [email protected]; > Gervase Markham <[email protected]>; Wayne Thayer <[email protected]> > *Subject:* Re: Possible Issue with Domain Validation Method 9 in a shared > hosting environment > > As suggested, we encourage you to work on devising technical mitigations > or alternative methods of validating such certificates that can meet the > use case. We don't think that, as described, the OneClick method meets the > necessary level of assurance, nor do the necessary level of mitigating > factors exist, to consider such certificates trustworthy. > > > > Ryan – I’m at a loss. The security threat is that a user can request a > certificate for a domain they don’t own from hosting companies that permit > SNI mappings to domains the user doesn’t own or control. This permits them > to pass validation for a domain they don’t control that is on the same IP > address as their legitimate site (or at least to which they have this level > of SNI control). We will verify that our OneClick customers will request > certificates for domains the hosting company is actively managing for their > users and not permit malicious actions (much like LE verifying that their > hosting companies do not permit “acme.invalid” domains to be used). This > eliminates the problems of SNI being used as an avenue for domain > validation for malicious actors. Is this not sufficient for some reason? > > > > Surely you agree that within non-shared hosting environments OneClick is > not vulnerable and can be used. > > > > No, it's not sufficient. > > > > The failure mode unfortunately necessarily includes a failure by > GlobalSign process and/or personnel, and in that failure mode, there are > further no mitigating factors. > > > > - If GlobalSign adds a vulnerable entity to their whitelist > > - The certificates issued will be valid for 1-3 years, leaving only the > (broken) revocation system as recourse > > We can and will reduce max validity to 6 months as a standard > configuration option within our system. > I'm glad to here - but I hope you can see this is still over twice the upper-bound for the acceptable safety margin of 90 days. On this point, we really don't think there's room to be flexible here. 90 days represents the tolerable maximum, assuming a perfect set of mitigations. > - There is no step organizations can take to pre-emptively mitigate the > risk of GlobalSign adding to the whitelist (compared to, say, blocking > .invalid) > > Actually, there is and I apologize for not making this more clear before. > We have site operators that manage the issuance of certificates for their > users. End users have no access to the issuance process, in uploading test > certificates to their sites, or any involvement in the issuance process as > this is automated by the site operators. Given this approach is verified > with the provider, we would propose whitelisting the account. > I'm not sure that really addresses the concern. There's nothing a site provider who is a GlobalSign customer can do to prevent GlobalSign from making an improper whitelisting mistake here - no technical ability to thwart users from using the method if said users can convince GlobalSign to add to the whitelist. Put more generically - this method is entirely reliant on the maintenance of that whitelist as a mitigation, and that entirely rests upon the CA. Much for the same reason that 3.2.2.4.11 was unacceptable, a method of validation which cannot be mitigated against is problematic, both in the case of pre-existing customers and new customers. > > > - There is no ability for site operators to detect such situations. A > consideration, not listed within the full set when discussing Let's Encrypt > and the ACME TLS-SNI method, is that we have at least public commitment by > Let's Encrypt and demonstrated evidence of sustained/long-term compliance > with publicly disclosing all issued certificates ( as noted in > https://letsencrypt.org/certificates/ ). While I realize you've offered > to do so, I can find no evidence of GlobalSign doing so by default, and so > this further adds to the risk calculus of a commitment to do something not > yet practice and thus not yet consistently, reliably delivered on. > > We currently include SCTs in all certificates we issue with the possible > exception of some Enterprise customers that prefer to keep their OV > certificates private (at least for now). This has been configured since > mid-November for all GlobalSign SSL products. > Thanks for clarifying! I had missed https://support.globalsign.com/customer/en/portal/articles/2534583-rolling-out-certificate-transparency-to-domain-validated-ssl was completed > I would encourage GlobalSign to consult Sections 3.2.2.4 and 3.2.2.5 to > see if there are any other alternative methods to validating that might > represent an appropriate balance. Given that these are posed as automated > certificates, there seem that other methods may be suitable for the > issuance of Domain Validated certificates - or, with care, Organizational > Validated. If it truly is that none of these other methods (outside > 3.2.2.4.9 and .10, and understandably the in-discussion-for-removal .1 and > .5), are there steps that can be taken that provide concrete technical > mitigations (ideally, through an opt-in technical signal by the site > operator) that can reduce or eliminate this risk? Are there steps that can > be taken with policy to similarly address the concerns? > > There are some use cases where the provider does not control DNS or web > site content, so moving to another method is not automated. Certainly with > the issues with methods 9 and 10 for shared IP address providers, we hope > an alternate approach is identified and rolled out as a new BR Domain > Validation method. > Did you have a chance to review https://groups.google.com/d/msg/mozilla.dev.security.policy/PiOiGCyuxCU/ISvCL4GJAQAJ ? _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
