Hello,
First of all let me state that I am in no way involved in the operation of
a certificate authority, nor am I involved in setting CA policy for any
organisation; I am merely an interested observer. I am a user of Mozillas'
trust store, both directly through Firefox and Thunderbird, and indirectly
by using pieces of software that rely on NSS. I have previously been a
customer of WoSign[0], but am not currently.
Addressing Mozillas' response to WoSigns' breach:
* Surely there is precedent from previous violations by other CAs that can be
used to inform this decision? How did Mozilla handle the October 2015
incident[1] in which Symantec mis-issued over 2500 certificates? While the
scale appears to be different, the facts of that incident are not too
dissimilar to this one; a CA mis-issued a number of certificates, and
failed to adequately notify trust store operators of this.
* While there doesn't seem to be a great deal of dispute over the facts of
this incident, it seems to me that in the very short term (ie, the next
fortnight) it would be useful if WoSign were required to produce an incident
report detailing:
- The precise extent of the incident, detailing every certificate that was
mis-issued and to whom, to reassure the community that these bugs are not
being used maliciously
- The current status (revocation, CT presence) of all mis-issued
certificates.
- An assessment as to the cause of the incident[2]
- Details as to the measures already undertaken to rectify the defects
- Details of future measures that will be undertaken to prevent further
problems
The purpose of this is to re-establish some small amount of trust that WoSign
can be permitted to continue operating while a longer-term plan is discussed
* I do not know what should be done in the longer term, but I suggest that the
focus of this discussion be on finding ways to permit WoSign to prove that
they are fit to participate in the Root Trust programme, so long as WoSign
are willing to engage and proactively work to restore trust. If WoSign do
not wish to work to restore trust, then removal from the programme would
have to be considered. Care must be taken to not unduly punish WoSigns'
customers, while at the same to the safety of the wider internet community
must be assured.
Addressing this issue in general; WoSign have claimed that their failure to
report this incident came about from a misunderstanding of the English
language documents by their staff who do not all speak English. While this
is clearly not a valid excuse, is this something Mozilla needs to consider
to prevent similar incidents in the future? Surely a significant
proportion of CA operators face a similar language barrier?
Thank you all for your time,
Will Hughes
[0] I issued two certificate via WoSign in May 2016 for hosts that were
not internet facing, because it was impractical for me to issue LetsEncrypt
certs for those hosts. I have since updated my tooling, issued LetsEncrypt
certs and revoked the WoSign certs. I note that neither of the WoSign certs
appear on crt.sh
[1]
https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html
[2] I understand that in the short timeframe, a full post-mortem may not
be practical, but an initial assesment of the causes of the incident
should have already been completed
On Thursday, 25 August 2016 01:09:02 UTC+12, Gervase Markham 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
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
