Your top 10 or top 5 is not same as my top 10 or top 5. BTW, Dangdang.com is using our certificate: https://www.ssllabs.com/ssltest/analyze.html?d=login.dangdang.com&latest
Some is also using our certificate that you don't know. Regards, Richard > On 8 Sep 2016, at 23:59, Ming <[email protected]> wrote: > > 在 2016年9月7日星期三 UTC+8下午6:08:33，Richard Wang写道： >> Hi Gerv, Kathleen and Richard, >> >> This discuss has been lasting two weeks, I think it is time to end it, it >> doesn’t worth to waste everybody’s precious time. >> I make my confession that our system and management do have some problems >> which lead to the misissuance of some certificates. And I am very sorry that >> WoSign don’t notify all browsers after the incident happened and even after >> the problem fixed. >> >> I’d like to give my suggestion action for Mozilla as below: >> 1. Mozilla will trust those SSL certificates only: >> (1) The certificate notBefore date is before Jan. 1st 2015; >> (2) The certificate notBefore date is from Jan. 1st 2015 to July 4th 2016 >> that listed in the Google CT log server; >> (3) The certificate notBefore date is from July 5th 2016 to Sept xx 2016 >> that embedded SCT data in the certificate; >> (4) The certificate notBefore date is from Sept xx 2016 that embedded SCT >> data in the certificate and must have the “C=CN” in the certificate subject. >> >> 2. Mozilla can assign a WebTrust auditor to WoSign office to check and >> inspect every incident, check every relevant issued certificate, and record >> a report with: what happened, why this happened and what is being done to >> prevent this in the future etc., WoSign will pay the audit cost. >> >> I’d like to make some supplements about 1. (4) above, this term means WoSign >> will only issue SSL certificates to China subscribers. >> WoSign issued about 120K SSL certificates for websites in China including >> many central government websites like MIIT and many other local province >> government websites, many university websites, many online banking websites, >> 6 of the Top 10 ecommerce websites, big supermarket online store like >> Walmart, 4 of the Top 5 cloud service in China, and many big companies that >> listed in NYSE and Nasdaq, and many subsidiaries of foreign countries big >> companies. > > Richard,I check the top 10 e-commerce websites in China, ONLY suning.com and > yhd.com are your subscribers; and ZERO of the top 5 cloud service companies > in China use WoSign. > > I have reason to doubt the authenticity of the data you provided. > > there is the top 10 e-commerce websites in China: > taobao.com > jd.com > tmall.com > amazon.cn > vip.com > meituan.com > suning.com > dangdang.com > jumei.com > yhd.com > > the top 5 cloud service companies in China: > aliyun.com > qcloud.com > qingcloud.com > ucloud.cn > hwclouds.com > > >> Those customers like to use WoSign certificate especially our support of >> Chinese, local support and customer service. And some of them paid up to >> 10-year certificate fee in advance, we need to renew their certificate for >> free once it is about to expire at every three years for OV SSL. >> >> I wish Mozilla could accept my suggestion, and I am sure WoSign will do it >> better after getting this so big lesson. >> Thank you. >> >> >> Best Regards, >> >> Richard Wang >> CEO >> WoSign CA Limited >> >> >> -----Original Message----- >> From: dev-security-policy >> [mailto:[email protected]] On >> Behalf Of Richard Wang >> Sent: Sunday, September 4, 2016 5:49 PM >> To: Gervase Markham <[email protected]>; >> [email protected] >> Subject: RE: Incidents involving the CA WoSign >> >> Hi all, >> >> We finished the investigation and released the incidents report today: >> https://www.wosign.com/report/wosign_incidents_report_09042016.pdf >> >> This report has 20 pages, please let me if you still have any questions, >> thanks. >> >> This report is just for Incident 0-2, we will release a separate report for >> another incident X soon. >> >> >> Best Regards, >> >> Richard Wang >> CEO >> WoSign CA Limited >> >> >> -----Original Message----- >> From: Gervase Markham [mailto:[email protected]] >> Sent: Wednesday, August 24, 2016 9:08 PM >> To: [email protected] >> Cc: Richard Wang <[email protected]> >> Subject: Incidents involving the CA WoSign >> >> Dear m.d.s.policy, >> >> Several incidents have come to our attention involving the CA "WoSign". >> Mozilla is considering what action it should take in response to these >> incidents. This email sets out our understanding of the situation. >> >> Before we begin, we note that Section 1 of the Mozilla CA Certificate >> Enforcement Policy[0] says: "When a serious security concern is noticed, >> such as a major root compromise, it should be treated as a >> security-sensitive bug, and the Mozilla Policy for Handling Security Bugs >> should be followed." It is clear to us, and appears to be clear to other CAs >> based on their actions, that misissuances where domain control checks have >> failed fall into the category of "serious security concern". >> >> Incident 0 >> ---------- >> >> On or around April 23rd, 2015, WoSign's certificate issuance system for >> their free certificates allowed the applicant to choose any port for >> validation. Once validation had been completed, WoSign would issue >> certificates for that domain. A researcher was able to obtain a certificate >> for a university by opening a high-numbered port (>50,000) and getting >> WoSign to use that port for validation of control. >> >> This problem was reported to Google, and thence to WoSign and resolved. >> Mozilla only became aware of it recently. >> >> * Before the recent passage of Ballot 169 in the CAB Forum, which limits the >> ports and paths which can be used, the Baseline Requirements said that one >> acceptable method of domain validation was "Having the Applicant demonstrate >> practical control over the FQDN by making an agreed‐upon change to >> information found on an online Web page identified by a uniform resource >> identifier containing the FQDN". This method therefore did not violate the >> letter of the BRs. However, Mozilla considers the basic security knowledge >> that ports over 1024 are unprivileged should have led all CAs not to accept >> validations of domain control on such ports, even when not documented in the >> BRs. >> >> * The misissuance incident was not reported to Mozilla by WoSign as it >> should have been (see above). >> >> * This misissuance incident did not turn up on WoSign's subsequent BR >> audit[1]. >> >> Incident 1 >> ---------- >> >> In June 2015, an applicant found a problem with WoSign's free certificate >> service, which allowed them to get a certificate for the base domain if they >> were able to prove control of a subdomain. >> >> The reporter proved the problem in two ways. They accidentally discovered it >> when trying to get a certificate for med.ucf.edu and mistakenly also applied >> for www.ucf.edu, which was approved. They then confirmed the problem by >> using their control of theiraccount.github.com/theiraccount.github.io to get >> a cert for github.com, github.io, and www.github.io. >> >> They reported this to WoSign, giving only the Github certificate as an >> example. That cert was revoked and the vulnerability was fixed. However >> recently, they got in touch with Google to note that the ucf.edu cert still >> had not been revoked almost a year later. >> >> * The lack of revocation of the ucf.edu certificate (still unrevoked at time >> of writing, although it may have been by time of posting) strongly suggests >> that WoSign either did not or could not search their issuance databases for >> other occurrences of the same problem. Mozilla considers such a search a >> basic part of the response to disclosure of a vulnerability which causes >> misissuance, and expects CAs to keep records detailed enough to make it >> possible. >> >> * This misissuance incident was not reported to Mozilla by WoSign as it >> should have been (see above). >> >> * This misissuance incident did not turn up on WoSign's subsequent BR >> audit[1]. >> >> Incident 2 >> ---------- >> >> In July 2016, it became clear that there was some problems with the >> StartEncrypt automatic issuance service recently deployed by the CA >> StartCom. As well as other problems it had, which are outside the scope of >> this discussion, changing a simple API parameter in the POST request on the >> submission page changed the root certificate to which the resulting >> certificate chained up. The value "2" made a certificate signed by "StartCom >> Class 1 DV Server CA", "1" selected "WoSign CA Free SSL Certificate G2" and >> "0" selected "CA 沃通根证书", another root certificate owned by WoSign and >> trusted by Firefox. >> >> Using the value "1" led to a certificate which had a notBefore date (usage >> start date) of 20th December 2015, and which was signed using the >> SHA-1 checksum algorithm. >> >> * The issuance of certificates using SHA-1 has been banned by the Baseline >> Requirements since January 1st, 2016. Browsers, including Firefox, planned >> to enforce this[2] by not trusting certs with a notBefore date after that >> date, but in the case of Firefox the fix had to be backed out due to web >> compatibility issues. However, we are considering how/when to reintroduce >> it, and CAs presumably know this. >> >> * The issuance of backdated certificates is not forbidden, but is listed in >> Mozilla's list of Problematic Practices[3]. It says "Minor tweaking for >> technical compatibility reasons is accepted, but backdating certificates in >> order to avoid some deadline or code-enforced restriction is not." >> >> * WoSign deny that their code backdated the certificates in order to avoid >> browser-based restrictions - they say "this date is the day we stop to use >> this code"[4]. If that is true, it is not clear to us how StartCom came to >> deploy WoSign code that WoSign itself had abandoned. >> >> * It seems clear from publicly available information that StartCom's >> issuance systems are linked to WoSign's issuance systems in some way. >> Nevertheless, it should not have been possible for an application for a cert >> from StartCom to produce a cert signed by WoSign. >> >> * This misissuance incident was not reported to Mozilla by WoSign as it >> should have been. >> >> >> Taking into account all these incidents and the actions of this CA, Mozilla >> is considering what action to take. Your input is welcomed. >> >> Gerv, Kathleen and Richard >> >> >> [0] >> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/enforcement/ >> [1] https://cert.webtrust.org/SealFile?seal=2019&file=pdf >> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=942515 >> [3] >> https://wiki.mozilla.org/CA:Problematic_Practices#Backdating_the_notBefore_date >> [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1293366 >> _______________________________________________ >> dev-security-policy mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-security-policy > > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
