To the policymakers at Mozilla, my name is Samuel Pinder. I consider myself an computer network analyst and have a degree in Web Systems Development. I also host a small number of websites on a technical level. I have used Startcom's services for a number of years. I only recently came across WoSign when I discovered that they offer 3-year valid certificates for free for up to 5 hostnames. That seemed quite an excessively long time in my opinion for a free certificate, almost too good to be true. As a customer of effectively both WoSign and Startcom, I have been having gradually growing concerns for some time about their recent practices and this recent news has not helped. I am currently looking into using other CA's for my needs but will watch what happens next closely before making a decision. I firmly believe WoSign have almost 'purchased' Startcom as I noticed that the nameserver domain for startssl.com (namely startcomca.net) would bring up WoSign's website for a time when accessed via a web browser as www.startcomca.net. I personally emailed Eddy Nigg (Startcom founder) about this, and this was eventually changed to redirect to startssl.com. So it is obvious that WoSign is hosting/sharing Startcom's infrastucture on it's own CA hardware/software, which Eddie confirmed in his email reply. The SSL certificate at the time for www.startcom.org had expired for over a week and still does have many broken links. Using the 'Live Chat' on www.startssl.com had a very confused employee tell me that startcom.org is no longer the website for Startcom, but startssl.com is. I stressed that this was confusing to people and that they should redirect the latter if that's the case. However... startcom.org remains using Israeli-based nameservers. Just how closely related Startcom is to WoSign is unknown, but it does mean that almost anything that renders WoSign vulnerable, also applies to Startcom. I would hope that Startcom re-evaluate their relationship with WoSign following this mess at the very least. Regarding WoSign in particular, the SHA-1 miss-issued certificates does look like a genuine mistake, being issued off of an SHA-2 intermediate makes their existence rather pointless in the case of backward compatibility, as old operating systems need a whole SHA-1 chain to validate properly. So there is no obvious motive for this API functionality to be left there on purpose, unless.... a rogue employee/subcontractor left it in place for when a SHA-1 hash collision becomes possible? What is likely here is that SHA-1 used to be the default signature choice, and was indeed legacy functionality left behind. It is very concerning however that despite WoSign having an external audit (which all CA's are meant to have) it appears nobody has independently performed a code audit of their API backend to prevent this being possible in a production environment. With regards to the mis-issued certificates applying to whole base domains validated only sub-domain, that prospect is horrifying. With regards to WoSign's API following 301 redirects from one domain to another though, I have noticed that Let's Encrypt's API (another CA at letsencrypt.org) also has this behaviour. This may be standard behaviour of the ACME protocol. Perhaps it would be prudent to decide in overall policy whether 301 redirects of verification URLs are acceptable. There are legitimate reasons why this would happen, for example if a customer owned www.example1.com and www.example2.net, but wanted the latter to always redirect to the other (because for example of a name change, but had many hardcoded https:// links), they would otherwise have to temporarily disable the redirect to get an SSL certificate covering both domains when validating with this method. With regards to ports other than 80 and 443 and 8080 being used for validation, I think the motive of this is because China has a mandatory media licencing requirement (ICP licence) for all servers that operate on either ports. It may not be practical for an individual in China to get one of these licences just to be able to gain an SSL certificate with this validation method. Of course allowing higher numbered ports does not give much excuse. I tested WoSign's website today however and can confirm that they have removed URL-based file verification, and now only allow DNS or email (from WHOIS) validation. All that's well and good, but the fact remains that there could be many other mis-issued certificates already in existence and the scope remains unknown at this point just how many. We only have WoSign's word that all of the mis-issued certificates are known and/or revoked. If it cannot be certain that WoSign have revoked all incorrectly-validated certificates, then the obvious choice is to add the "WoSign CA Free SSL Certificate G2" intermediate to OneCRL, and possibly their DV intermediate too, as these intermediates are known to have mis-issued certificates whilst their other intermediates have always had tighter validation requirements for OV and EV validation. That approach would certainly be painful for existing users and would require WoSign to immediately contact current and past customers to have new certificates issued from a new intermediate, once it is certain that all the bugs in the validation procedures have been resolved. Would it be appropriate to give customers time before such action is taken, given that it would break many websites, or does the risk of data leaks from unknown mis-issued certificates outweigh the need to give customers time? The other option of simply preventing any newly-issued certificates from being accepted in browers does not seem a very good idea given that WoSign have been known to backdate certificates. In fact, I would even suggest that WoSign cease issuing free certificates (and most possibly paid DV certificates) and in the meantime have an independent audit of their backend to ensure all vulnerablities are closed, with the results made public. Only then should they recommence issuance- at least on an automated scale. GlobalSign did something similar to this when there was speculation that the hacker responsible for compromising Diginotar had also breached them, at great risk to their business but ultimately gained respect in the process. Given the severity of these incidents and the fact they went unreported though I would not be surprised if WoSign's whole roots are blacklisted eventually if WoSign do not get their act together. The promise to completely commit to Certificate Transparency is quite a step, but it does not change what has already happened. WoSign's recent announcement gives me the impression they expect others to manually scour the CT logs once they upload their 2015 certificate data for mis-issuances that need revoking rather than do this themselves. Whilst it may *technically* be 'transparent' with CT, they don't seem in the spirit of things being completely transparent with their practices- in particular the relationship between Startcom and WoSign. At least one of these incidents actually occurred during research into Startcom, and it turned out the API was being shared by both CA's. Given the circumstances, I think it is appropriate to ask just what the relationship is between them. For me, it appears they are now one and the same, while the original 'Startcom' infratructure I once trusted is gathering dust and has been abandoned. I think I'll be taking my needs to another CA very soon if things don't look up! Samuel Pinder
On Wednesday, 24 August 2016 14:09:02 UTC+1, 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
