In this post we discuss the events that have taken place around the Certificate Authorities StartCom and WoSign since Computest published about an important vulnerability in StartCom’s StartEncrypt product at the end of June. The discussion that was started in part because of this publication is interesting to follow, because it raises important questions about the core of trust on the internet, open collaboration between private parties and the community and the role of trust in Certificate Authorities in general.
The StartEncrypt tool by StartCom is intended to simplify the process of obtaining and installing certificates, but due to several vulnerabilities, it was relatively easily exploitable. One could get free certificates for others’ domains, and use those to impersonate for instance google.com or dropbox.com. StartCom reacted swiftly: part of the vulnerabilities was fixed within days.
Discussion about trustwortiness
By publishing about the vulnerability Computest wanted to fuel the discussion about the trustworthiness of Certificate Authorities (CAs): if a CA proves to have so little regard for security in their development and operations, what does this mean for trust in their certificate issuance? CAs are all about trust: they are the trusted third parties on the internet. When you want to connect to a website, like www.gmail.com, a certificate by a CA proves that you are indeed communicating with Gmail and not with an impostor. A “misissuance” (unrightfully issued certificate) is one of the capital sins for a CA.
The discussion was indeed fueled: on the bugtrackers and mailinglists of Mozilla, Google and Let’s Encrypt, discussions ensued over what this means for StartCom. Members of the CA/Browser forum (CA/Bf) also participated. CA/Bf is the collaboration forum between the CAs and browser vendors, where the baseline requirements (BR) for CAs are established.
Another capital sin: circumventing new regulation
However, StartCom committed another capital sin, one that was not highlighted in our publication. This mistake only caught our attention in a later analysis of our test data. While manipulating the API of StartEncrypt, in a certain case we were given a valid certificate that was signed using the SHA-1 algorithm, and was dated with a start date of December 20th 2015. That was strange in itself, since we were conducting our tests in June 2016, and the use of SHA-1 signatures is forbidden by the CA/Bf since January 1, 2016, because of its vulnerabilities. The certificate we were given dates from 2015, which makes it look like StartCom was trying to circumvent the new regulation. Perhaps their own infrastructure was not ready for SHA-256, or a large customer required the continued use of SHA-1 against the CA/Bf rules.
We made notion of this finding on the Mozilla security policy development mailing list and at their request also to Google Chrome’s security team. Furthermore, the backdated certificate that we obtained, wasn’t signed by StartCom but by WoSign, a Chinese CA. The relation between WoSign and StartCom is unclear (this is an interesting read with evidence and speculation). What is clear, is that WoSign and StartCom share infrastructure and that the CEO of WoSign also speaks on behalf of StartCom.
After being started, the discussion subsided pretty quickly. At least, that’s what it seemed like to the public: behind the scenes, WoSign and CA/Bf were continuing the discussion. Late August, Gervase Markham, an employee of Mozilla, published a summary of the incidents around WoSign. He concluded with the words “Mozilla is considering what action to take. Your input is welcomed.”
Removing a CA from the trust stores
While these words sound innocuous, they are quite ominous in the context of a browser and a CA. The browsers have little influence on the behavior of CAs, except for their ultimate disciplinary measure: removing a CA from the trust stores of their products. If Google for instance would decide to stop trusting WoSign, all users of the Chrome browser and Android devices would automatically stop trusting certificates that have been issued by WoSign. If another browser were to follow suit, the CA can practically close down: nobody will purchase a certificate there anymore.
Response to violations
With those words, a discussion with a significant volume of email traffic erupted. This discussion is taking a wrong turn for WoSign, with an increasing number of voices calling for the removal of WoSign (and/or StartCom) from the trust stores of browsers. The basis for this however isn’t the vulnerability that Computest discovered, since a vulnerability can happen to anyone and in itself does not constitute a violation of the BR. The real issue is the violations of the BR, and WoSign’s neglect in reporting those violations. This list of violations is becoming quite impressive:
- Incident 1: 16 January 2015 – 5 March 2015 – 1,132 BR-violating SHA-1 certificates ( https://cert.webtrust.org/SealFile?seal=2019&file=pdf )
- Incident 2: April 4, 2015 – WoSign is informed it’s routinely violating its CPS for issued certificates (https://www.wosign.com/policy/wosign-policy-1-2-10.pdf )
- Incident 3: April 9 – April 14, 2015 – 392 duplicate serial numbers
- Incident 4: April 23, 2015 – 72 potentially dangerous port-validated certificates
- Incident 5: June, 2015 – 33 unvalidated base-domain from sub-domain certificates
- Incident 6: July, 2016 – At least 1 backdated SHA-1 certificate numbering changed.
WoSign’s CEO throws around his sorrys, but doesn’t get much further than that in terms of mitigations or preventative measures:
“We know how to do in the future, and believe me we will do this better.”
“Yes, I am so sorry for this, it is my fault that I guarantee never happen in the future.”
And now appears to have lost all hope in the discussion:
“This is my last formal statement for this issue that I am tired of this argument, I need to go to hospital now :-).”
Considerations
A clear and harsh summary of the violations of WoSign has been written by Ryan Sleevi , a CA/Bf member from the Chrome security team. At the same time, he describes the dilemmas around removing a CA from the trust store. There are technical considerations: what to do with certificates that have been issued so far and are in use? And organizational/political considerations: are these violations so severe that they warrant removal? Permanently or temporarily? Can they be included again, and under what conditions?
Whatever the outcome of the discussion will be, it is clear that the CA system is built on trust in the CA’s itself, which operate under greatly varying professionality.
What do you think should happen next?
