See below inline, thanks.
Best Regards, Richard -----Original Message----- From: Jeremy Rowley [mailto:jeremy.row...@digicert.com] Sent: Thursday, August 25, 2016 12:12 AM To: Gervase Markham <g...@mozilla.org <mailto:g...@mozilla.org> >; mozilla-dev-security-pol...@lists.mozilla.org <mailto:mozilla-dev-security-pol...@lists.mozilla.org> Cc: Richard Wang <rich...@wosign.com <mailto:rich...@wosign.com> > Subject: RE: Incidents involving the CA WoSign Gerv, On incident 0, its unclear whether a cert was actually mis-issued. Although they used a higher level port, did the researcher successfully bypass WoSign's domain validation process? Is the only concern that WoSign permitted higher level ports? R: No cert is mis-issued. Yes, all passed the standard website control validation, it is the case that permitted higher level ports from Jan. 8th, 2015 since some customer website don’t use 80 and 443 port. And this permit is disabled after Google reported. On incident 1, I agree this was a bad practice and should have been reported. I'd love an incident report from WoSign on it. Perhaps it was a language barrier in interpreting requirements? R: I am very sorry for this that we must report to all browsers, this will not happen in the future. Yes, all employees English level is not so good that bad than me. :( This is a bug in switching our validation system to new system. But we fixed it in time. We searched our database that we found there are 32 certificates mis-issued, we will post those certificate to log servers and revoke these certificate after noticing the subscribers. This case is adding subdomain rule bug, in order to give site visitor good experience, if the application for domain: <http://www.wosign.com> www.wosign.com, we will add domain wosign.com in the SAN for free, this case just for top domain wosign.com is validated. But for website control validation, we can’t use this rule, we fixed this bug after getting report from customers. On incident 2, it sounds like they are both using the same auto-generation script. This doesn't sound much different from what ACME is hoping to do. Backdating the cert seems sketchy but, as you pointed out, isn't expressly against the Mozilla policy or the Baseline Requirements. Giving WoSign the benefit of the doubt, it sounds like maybe it was a bug in their software that permitted SHA1 certs not an intentional back-dating issue. Is there any clarity around how this worked? R: Yes, we use the same auto-generation script like this way: parameter 2 post data to api.startssl.com, parameter 1 post data to api.wosign.com, parameter 3 post data to api.letsencrype.org. For backdated issue, as I described in the Bugzilla, this is a bug, and only Computest used this parameter to get two SHA1 certificate for API test and we revoked. Jeremy -----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert....@lists.mozilla.org] On Behalf Of Gervase Markham Sent: Wednesday, August 24, 2016 7:08 AM To: mozilla-dev-security-pol...@lists.mozilla.org <mailto:mozilla-dev-security-pol...@lists.mozilla.org> Cc: Richard Wang <rich...@wosign.com <mailto: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 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. 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 <http://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 <http://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. 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 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. 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". 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  https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/enforcement/  https://cert.webtrust.org/SealFile?seal=2019 <https://cert.webtrust.org/SealFile?seal=2019&file=pdf> &file=pdf  https://bugzilla.mozilla.org/show_bug.cgi?id=942515  https://wiki.mozilla.org/CA:Problematic_Practices#Backdating_the_notBefore_date  https://bugzilla.mozilla.org/show_bug.cgi?id=1293366 _______________________________________________ dev-security-policy mailing list firstname.lastname@example.org <mailto:email@example.com> https://lists.mozilla.org/listinfo/dev-security-policy
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list firstname.lastname@example.org https://lists.mozilla.org/listinfo/dev-security-policy