On Monday, September 12, 2016 at 2:46:40 PM UTC-7, Ryan Sleevi wrote: > On Wednesday, August 31, 2016 at 12:43:50 PM UTC-7, Nick Lamb wrote: > > I have spent some time thinking about this, but I am only one person, and > > one with relatively little in-depth knowledge of the Mozilla project, so I > > think I will lay out the options I've thought about and invite feedback > > though particularly any alternative suggestions. > > Returning to the topic of this thread, there were a number of alternatives > put forward that didn't raise to the summary level captured here: > > https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/hj_KMPGUDAAJ > > To recap, and to combine your suggestions, we have: > A) Distrust with option to manually add back > B) Distrust with no option to manually add back (aka Blacklist) > C) Distrust with Whitelist of Certs > C.1) Whitelist based on all certs (several hundred thousand) > C.2) Whitelist based Alexa Top 1M (~60 thousand) > D) Trust w/ Heuristic > D.1) Certs with notBefore < some date trusted implicitly, certs with > notBefore > some date are CT logged > D.2) Trust if C=CN is present in subject name (WoSign's proposal) > E) Trust w/ PR > E.1) Require some form of mandatory disclosure of misissuance > F) Trust w/o any action > > > Nick's proposal #1 is was already captured by D1 in the previous thread. > Nick's proposal #2 is captured by E1 > Nick's proposal #3 is captured by F (no concrete steps were proposed) > > I've not included the RP discussion in the above summary, because I don't > believe it talks to actions short of distrust, but about alternative methods > of determining trustworthiness. It doesn't provide an actionable framework, > for, say dealing with issues that arise when a CA behaves against the public > interest. > > > To that end, I'm going to offer one more suggestion for consideration: > G) Distrust with a Whitelist of Hosts > > The issue with C is that it becomes easily inflated by issuing certificates, > even if they're not used; that is, a free certificate provider can easily > exceed a reasonable size of a whitelist, by issuing many certificates for a > given host, even if they're not used. > > Whitelisting by hostname may offer a reasonable solution that balances user > need and performance. > > > Consider if we start with the list of certificates issued by StartCom and > WoSign, assuming the two are the same party (as all reasonable evidence > suggests). Extract the subjectAltName from every one of these certificates, > and then compare against the Alexa Top 1M. This yields more than 60K > certificates, at 1920K in a 'naive' whitelist. > > However, if you compare based on base domain (as it appears in Alexa), you > end up with 18,763 unique names, with a much better compressibility. For > example, when compared with Chrome's Public Suffix List DAFSA implementation > (as one such compressed data structure implementation), this ends up > occupying 126K of storage. > > 126K may be within the range of acceptable to ship within a binary. Further, > there are a number of things that can be done to reduce this overhead: > > 1) Large vendors (such as microsoft.com and amazonaws.com) appear within this > list, but likely don't wish to; this gives a natural reduction function > 2) This doesn't fully account for revocations > 3) It could be combined with, say, requiring CT for new certs. While this is > hardly a perfect function, given the backdating, it could effectively monitor > the issuance of new certificates. > 4) The Alexa list includes known third-party domain providers (e.x. > myqnapcloud.com, myasustor.com) that could be factored out, as they're not > centrally managed > 5) Names naturally expire on this list, giving a reasonable stepping function > > > This could be combined with a large scale distrust, and operates on the > theory that the primary concerns with a distrust event are minimizing user > impact, while allowing sites sufficient time to migrate, and this could offer > a one-or-two-release-cycle "graceful turndown" of a CA. If other browsers > were able to adopt such a solution, such that the industry could be in rough > harmony, this could offer a graduated point to distrust.
I totally agree with Ryan's approach. It seems to be the most practical way and quickest to implement considering the severity of the problems. A minor suggestion: Mozilla or Google can implement a public-facing portal for website owners to request them taking off from the whitelist. The portal can work like https://hstspreload.appspot.com/, but rather than checking the header, the portal can check whether it's using a non-Wosign/StartCom cert. Once verified, the hostname will be removed from whitelist in the next release. We can also run those kind of scans periodically to trim the whitelist. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
