在 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:dev-security-policy-bounces+richard=wosign....@lists.mozilla.org] On > Behalf Of Richard Wang > Sent: Sunday, September 4, 2016 5:49 PM > To: Gervase Markham <g...@mozilla.org>; > mozilla-dev-security-pol...@lists.mozilla.org > 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:g...@mozilla.org] > Sent: Wednesday, August 24, 2016 9:08 PM > To: mozilla-dev-security-pol...@lists.mozilla.org > Cc: Richard Wang <rich...@wosign.com> > 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 > 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
