Would this be enough? http://www.cac.gov.cn/2016-09/19/c_1119583763.htm
On Thursday, October 13, 2016 at 10:58:34 AM UTC+8, 谭晓生 wrote: > Yuwei, > I don’t know who you are, but I can tell you and the community, Qihoo 360 > never been involved in ***** Fire Wall project, if you did some investigation > to the message that accused Qihoo 360 joined the project “Search Engine > Content Security Management System”, you should know the project had been > done on Feb 2005, before Qihoo 360 was founded on Aug 2005, and the project > is neither part of the ***** fire wall project nor a project done by Qihoo > 360, actually it is part of the efforts to help Yahoo’s search engine could > work in China, I was the tech head of Yahoo!China ‘s tech team, director of > engineering and soon the CTO of Yahoo!China, I know what happened at that > time. > > Thanks， > Xiaosheng Tan > > > > 在 2016/10/13 上午5:22，“dev-security-policy 代表 Han > Yuwei”<dev-security-policy-bounces+tanxiaosheng=360...@lists.mozilla.org 代表 > hanyuwe...@gmail.com> 写入: > > 在 2016年10月13日星期四 UTC+8上午3:12:08，Ryan Sleevi写道： > > As Gerv suggested this was the official call for incidents with respect > to StartCom, it seems appropriate to start a new thread. > > > > It would seem that, in evaluating the relationship with WoSign and > Qihoo, we naturally reach three possible conclusions: > > 1) StartCom is treated as an independent entity > > 2) StartCom is treated as a subsidiary of Qihoo > > 3) StartCom is treated as a subsidiary of WoSign > > > > We know there are serious incidents with WoSign that, collectively, > encourage the community to distrust future certificates. However, there > hasn't been a similar investigation into the trustworthiness of StartCom as > an independent entity or as an entity operated by Qihoo. It would seem that > germane to the discussion is how trustworthy the claims are - from either > StartCom or Qihoo - and how that affects trust. > > > > Incidents with StartCom: > > A) Duplicate Serials. > https://bugzilla.mozilla.org/show_bug.cgi?id=1029884 > > We know that StartCom had issues issuing duplicate serials, in > violation of RFC 5280. We know that they did not prioritize resolution, and > when attempting resolution, did so incompletely, as the issue still > resurfaced. > > > > C) Improper OCSP responder. > https://bugzilla.mozilla.org/show_bug.cgi?id=1006479 / > https://bugzilla.mozilla.org/show_bug.cgi?id=1151270 > > We know that StartCom continues to have issue with their OCSP responder > after they issue certificates. Presumably, this is a CDN distribution delay, > but we can't be sure, especially considering Incident A was with the > underlying systems. As a consequence of this, users with StartCom > certificates are disproportionately disadvantaged from enabling OCSP > stapling, which many browser programs support (and is perhaps the only viable > path towards a complete revocation solution). > > > > E) Heartbleed. https://bugzilla.mozilla.org/show_bug.cgi?id=994033 / > https://bugzilla.mozilla.org/show_bug.cgi?id=994478 > > We know StartCom had a notoriously poor response to HeartBleed. Eddy > first dismissed the significance, and then when proven wrong, still continued > to charge $25 USD for revocation. Ostensibly, this is a violation of the > Baseline Requirements, in that CAs are required to revoke certificates > suspected of Key Compromise. However, despite the BRs effective date of 2012, > Mozilla was not aggressively imposing compliance then (... or now, to be > fair). > > > > G) StartCom BR violations - IV > https://bugzilla.mozilla.org/show_bug.cgi?id=1266942 > > StartCom was materially violating its CP/CPS and the Baseline > Requirements with respect to certain types of validation. No explanation for > the root cause provided. > > > > I) StartCom BR violations (2) - Key Sizes > https://bugzilla.mozilla.org/show_bug.cgi?id=1015767 > > StartCom was issuing certificates less than 2048 bits. > > > > K) StartCom impersonating mozilla.com. > https://bugzilla.mozilla.org/show_bug.cgi?id=471702 > > StartCom's (former) CEO Eddy Nigg obtained a key and certificate for > www.mozilla.com and placed it on an Internet-facing server. > > > > M) StartCom BR violations (3) - Key exponents > https://bugzilla.mozilla.org/show_bug.cgi?id=1212655 > > StartCom was not enforcing the BRs with respect to RSA public exponents. > > > > O) StartCom BR violations (4) - Curve violations > https://bug98304.bugzilla.mozilla.org/show_bug.cgi?id=1269183 > > StartCom was not enforcing the BRs with respect to EC curve algorithms. > > > > > > > > In addition to discussion of StartCom issues, it seems relevant to > future trust to evaluate issues with Qihoo. Many in the Mozilla community may > not have direct interactions with Qihoo, but they have obtained some > notoriety in security circles. > > > > Q.A) Qihoo masking their browser as a critical Windows security update > to IE users. > > http://wmos.info/archives/7717 / > http://www.theregister.co.uk/2013/02/01/qihoo_government_warning_fraud/ > > Qihoo displayed a misleading security update for Windows users that > instead installed their browser. > > > > Q.C) Qihoo browser actively enables insecure cryptography. > > > https://docs.google.com/document/d/1b7lenmn5XO06QohaJzVffnJxjXjY1rD70wg34gfuxRo/edit > > Qihoo's browser is notably insecure with respect to SSL/TLS, with some > of the insecure changes requiring active modification to the low-level source > libraries that Chromium (of which they're based on) uses. > > > > Q.E) Qihoo apps removed from app stores due to malware > > > https://www.techinasia.com/qihoo-committing-fraud-google-making-huge-mistake > / https://www.techinasia.com/qihoo-apps-banned-apple-app-store > > Qihoo Apps have repeatedly been banned from Apple's App Store due to > issues > > > > Q.G) Qihoo "security" apps repeatedly found as unfair competition > > > https://www.techinasia.com/qihoo-360-loses-chinas-courts-ordered-pay-sogou-82-million-unfair-competition > > > > > > > > I hope the above show that the odds are if the original StartCom > systems are restored, we're likely to continue to have significant BR > violations - a pattern StartCom has repeatedly demonstrated over several > years. Similarly, if we were to accept trust in Qihoo, then we would be > ignoring the precedent Qihoo has set of choosing insecure and anti-user > behaviours masked as "security". > > As a Chinese Internet user, I would say that Qihoo has a very negative > reputation on China online community for its precedent's malware(maybe not > accurate) and some awful actions such as "3Q Battle", installing software > sliently, misleading ads, suspiciously collecting data which is believed > helping govnerment monitoring citizens and so on. But on the other hand, > their product, "360安全卫士" (360 Total Security)(two names are not the same > version but I can't find another english name),as I thought, has improved the > total security level of China Internet. And it has changed the ecosystem of > Chinese anti-malware software,which I don't know it is good or bad. And it's > believed that Qihoo have a tight connection with the Great Fire Wall project. > > Since "The Big Brother is Watching you" is not accepted in Mozilla, I > thought Qihoo is not trustworthy in operating a CA. > > P.S. Anyone who knows to change the font size of google group? As a > non-english native speaker it is hard for me to read such a small size in the > content. > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
