WoSign totally issued 230K SSL certificates till now for worldwide websites about 208 countries and regions.
> > If browser vendors/root stores move to distrust WoSign, all of these certs > would be invalidated. We know that a number of sites within the Alexa Top 1M > are (intentionally) using WoSign, so we can expect a large number of users, > across browser vendors, are accessing these sites, and would thus be seeing a > significant amount of SSL/TLS error pages if the CA was distrusted. We know > that major platform providers (such as Microsoft Azure) have partnered with > WoSign as well, and thus further suggest a larger than desired user impact. // Microsoft Azure China has moved from CNNIC to WoSign and ultimately to DigiCert and I assume many large companies will follow suit. If they have not, they will certainly do once they're aware WoSign is pending removal (if removal is decided) > > > Setting aside for a second whether or not distrusting is the right action, > let's think about what possible responses. > > A) Remove the CA. Users may manually trust it if they re-add it, but it will > not be trusted by default. > B) Actively distrust the CA. Even if manually added (by user or enterprise > policy), it will not be trusted. > C) Remove the CA. Develop a whitelist of pre-existing certificates to be > trusted. > - What form should this whitelist take? > * Shipping it in the binary is unacceptably large. > * Downloading it in full on demand is unacceptably large/unreliable. > * Checking with a central server for serial number can lead to misleading > results (WoSign has shown they issue duplicate serials, and nothing would > prevent them from doing so in the future) > * Checking with a central server for certificate hash may have privacy > considerations. > * Conclusion: Something SafeBrowsing-like would have to be developed ( > https://developers.google.com/safe-browsing/v4/ ), which could be months away. > D) Distrust any certificate without appropriate CT information. Whitelist > certs before 2016. > - See whitelist problems above > E) Distrust certs without appropriate CT information, wholesale. > - Note: It appears that WoSign is or has had similar issues to Symantec, > failing to log to a diverse-enough set of logs to ensure a robust CT > implementation. A quick and random sampling shows, for example, that > precertificates are only being logged to Google logs (such as for 8-30-16). > Thus, unless an implementation is willing to fully trust Google CT logs alone > - something Google themselves are unwilling to do - then this suggests that > this may be the same as wholesale distrusting. > > In effect, a number of these options boil to a set of concerns: > - Distrusting can be significantly disruptive to end-users, potentially > habituating them to SSL warnings or errors > - Distrusting potentially could interfere with those who may still want to > trust WoSign manually, themselves > - Distrusting in a way that minimizes disruption has concerns for privacy, > stability, or timeliness. > > I'm not trying to suggest that distrusting is right or wrong, but I am > curious for those who would advocate distrusting how browser vendors, such as > Google and Mozilla, for example, might appropriately balance the concerns of > the broader community, while also minimizing any damage, particularly to > their users, and avoiding any reactionary responses. Indeed, WoSign has become too big to fail. I would suggest that the decision whether to remove WoSign should be independent of whether it's practical to implement such removal. Otherwise, larger CA basically gained "natural protection" from mere usage numbers over smaller CA in terms of enforcement actions. On the practical implementation, I suggest the following. All existing certs issued by WoSign need to be logged by enough CT logs by say Dec 31, 2016. After Jan 1, 2017, the browser will only trust a cert from WoSign if 1) CT is present 2) The cert is submitted to CT logs before Dec 31, 2016. Or we can use an offline whitelist. How about include SHA-2 of existing WoSign certificates in the binary? So the browser would first check whether it's signed by WoSign, if so, compare the hash of the cert with the offline list. 224 bit hash * 230K certificate = 6.5 MB. Considering the Chrome installer file is almost 70MB, this might be acceptable. > > It would seem like a form of whitelist (whether to continue trusting WoSign > with CT enablement, or distrusting but grandfathering in disclosed certs, ala > CNNIC) would require active development and assistance from the broader > security and privacy community on how best to balance and scale such > concerns, and regardless, would take time to implement, test, and deploy, but > would be useful and possibly scalable for other future CA incidents. However, > are there alternatives or concerns that I omitted from the above list? > > In either event, hopefully this thought experiment brings into light the set > of concerns that vendors, such as Mozilla and Google, may have to consider, > and may help find an appropriate response that reflects the gravity of these > incidents, and the handling of them, and may spark the community for ideas > and solutions that can help balance those needs. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
