On Wednesday, October 12, 2016 at 12:12:08 PM UTC-7, Ryan Sleevi wrote: > 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".
https://kyfw.12306.cn/otn/ is the page that 12306 uses self-signed cert. The standard practices now is to requires users of 12306(which would be hundreds of millions of Chinese users) to manually import the root CA http://www.12306.cn/mormhweb/ggxxfw/wbyyzj/201106/srca12306.zip. In fact, on the front page http://www.12306.cn/, the statement is highlighted in blue that "In order to buy train tickets, please install root CA". However, the root CA and the leaf cert is RSA not SM2. I speculate that such manual import of Root CA could be used for MITM, perhaps in a more targeted fashion than self-signed cert by GFW. Xiaosheng Tan, if 360 is to pin the such cert for 12306, please pin the leaf cert rather than include the SRCA in the root store. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
