For the thread's reference, here's the crt.sh link for the misissued GitHub certificate:
https://crt.sh/?id=29647048 Valid for 3 years, for github.com. It's not in OneCRL, CRLset, or Microsoft's disallowedcert.stl. On Wed, Aug 24, 2016 at 9:08 AM, Gervase Markham <[email protected]> wrote: > 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 > -- konklone.com | @konklone <https://twitter.com/konklone> _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
