Can you list the China top 10 e-commerce websites and the China top 5 cloud service companies in WoSign's opinion？ In this web page: https://www.wosign.com/english/Who_uses_wosign.htm, I only find yhd.com dangdang.com and suning.com are famous e-commerce websites in China.
2016-09-09 0:14 GMT+08:00 Richard Wang <rich...@wosign.com>: > 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 <moonbingb...@gmail.com> 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: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-policy@ > 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 > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
