Hi, section 1.4. Impact Analytics in the report contains a list of 72 certificates, for which the domain validation was done on a high port.
On 2015-04-20 I have obtained a certificate for a domain name that I validated using port 8080 but that certificate is not listed in the report. This is the certificate: https://crt.sh/?id=30335331 It seems like the certificate was posted to the CT logs by WoSign (at least I never used the certificate anywhere) but not on August 26th like the other certs and as stated in the report. So I have doubts about the report and it really should be investigated why this certificate is missing in the report. Regards, Julian Brost On 04.09.2016 11:49, Richard Wang wrote: > 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:ge...@mozilla.org] > Sent: Wednesday, August 24, 2016 9:08 PM > To: mozilla-dev-s...@lists.mozilla.org > Cc: Richard Wang <ric...@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 >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
