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.
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
