I also find it funny they have fired the CEO (the PDF does not say he stepped down voluntarily) but he's the one sending that link to the mailing list. I call bs.
I didn't realize this until I first visited China, but there are parts of the world where it's really hard to find people fluent in English. If you require people to be fluent in English in order to participate in running the Internet you're locking a large number of world regions out.
And that's all it is, really. Stuff that just screams, "Did no one proofread this thing before sending it out?" Probably not. Because whoever wrote it was probably the most fluent person at the company.
---
FWIW, I have native-English speaking programmer friends who ask me to proofread their stuff. I don't mind. One is an amazing programmer, but his writing ability is somewhere around 9th-grade proficiency. The fact remains that being able to write correctly is considered a "bare minimum" quality in the professional world, and it doesn't matter if you wrote your own virtual machine in Assembly in your spare time--if you sound like a college dropout in your resume, they'll skip over you.
It is similarly difficult to inspire confidence in a CA when their "transparency report" sounds unprofessionally cobbled together.
Reading knowledge of a language can be gotten fairly quickly.
If you're going to make fun of someone's English then you should probably write better English yourself. At the end of the day English isn't their first language and they'll probably very rarely have to use English. I think some slack should be given on this front.
The CA/Browser Forum Baseline Requirements and the mailing list discussions all happen in English. The major root programs all use English as their language of communication, to the best of my knowledge. The SSL/TLS and X.509 specifications are in English. The major browsers and TLS stacks have technical documentation, code comments, and code review in English. mozilla.dev.security.policy is in English. The international language of scientific research (including cryptographic research) is in English. The CVE program is in English. All of these are reasons not only to have people who are fluent in technical English, but to make hiring such people a priority.
In particular, the inability to communicate precise, subtle technical concepts was very relevant to some of the problems here, like "You may not issue SHA-1 certs after this date" meaning the actual, calendar date of issuance and not the recorded validity period in the certificate. (There was also an element of malice, but it could have gotten sorted faster if communication were easier.) Even if all the others were in some other language, the CA/Browser Forum alone would be enough to make anyone who wants to be a CA (or an HTTPS client implementor) must make fluency in technical English a priority.
It is, of course, highly unfortunate that people from non-Anglophone countries are at a disadvantage here. In an ideal world we wouldn't have that disadvantage. But there doesn't seem to be a way around picking a language to be the scientific lingua franca.
WoSign runs a business that is basically based on trust, and Nigerian scammers have sent me PDFs that looked far more convincing and trustable than that one WoSign posted.
That's not how the CA system works. Your security is unaffected by what CA you choose; it is invariably the minimum of all trusted CAs.
I'd rather have a system where the same criteria apply to all CAs independent of their jurisdiction, coupled with mechanisms that guarantee transparency (like Certificate Transparency) and stuff like key pinning.
I'm always skeptical of whether replacing a few executives can actually fix the cultural problems that were fostered/ignored in a company over time. The new leadership has to overcome a lot of inertia, and that's assuming they're any better than the old. They're also still answering to the same investors and pressures.
I also wonder how much more effort they thought it was to write the code to backdate the certs (rather than use "now") v.s. code for upgrading to SHA-256.
Wosign was certainly capable of issuing SHA-256 certificates. But the customers needed SHA-1 certificates with a backdated issue timestamp. And Wosign was willing to fake the issue timestamp on new certificates, probably a lucrative market because no other reputable CA would be willing to do so.
So they had a special side deal to get backdated certs? There's no way they were doing this for everybody or for "regular price" right?
We should be thanking them for their free certs, and thanking them again now for giving us another example of how the PKI is a farce. The chances are there are a bunch other 'reputable' CAs out there playing these games.
Mozilla have an excellent explanation document covering the backdated certs in detail here: https://docs.google.com/document/d/1C6BlmbeQfn4a9zydVi2UvjBG...
(Thanks to @xnyhps for the link in a reply to this comment.)
WoSign, described elsewhere as China's largest certificates authority, are a CA who have been found to have backdated SHA1 ceritificates to work around browser restrictions on SHA1 cert issueances. SHA1 is no longer considered secure. Resolution of that issue is discussed in new mozilla.dev.security.policy Usenet group peered by Google Groups: https://groups.google.com/forum/#!msg/mozilla.dev.security.p...
A better source for WoSign's update to the story is in the PDF posted to the newsgroup, here: https://www.wosign.com/report/WoSign_Incident_Report_Update_...
Titled "WoSign Incidents Report Update". Which is even less descriptive than the title presently given on this HN post, though perhaps what HN posting guidelines prefer. I'll let @dang wrestle his conscience on that one.
In that document are several issues listed, the one relevant to this HN post appears to be:
"9. Issue S: Backdated SHA-1 Certs (January 2016)
"WoSign has issued certificates after January 1st 2016 but backdated the notBefore date to be in December 2015. This has the effect of avoiding the blocks in browsers regarding SHA-1 certs issued after January 1st 2016. The number of certs affected is probably 67, but may be a few more or less."
Following down from there, several corporate restructuring steps are mentioned, including:
360’s Corporate Development team has been notified to execute the process to legally separate Wosign and Startcom and to begin executing personnel reassignments. StartCom’s chairman will be Xiaosheng Tan (Chief Security Officer of Qihoo 360). StartCom’s CEO will be Inigo Barreira (formerly GM of StartCom Europe). Richard Wang will be relieved of his duties as CEO of WoSign.
There is background on the story from:
"WoSign Mis-Issued SHA-1 SSL Certificates [Updated]" (August 24, 2016) https://www.thesslstore.com/blog/wosign-mis-issued-sha-1-ssl...
"Mozilla Ready to Ban WoSign Certificates for One Year After Shady Behavior" (September 26, 2016)
The second article details Mozilla's issues with WoSign, including purchase of an Israeli CA, StartCom http://news.softpedia.com/news/mozilla-ready-to-ban-wosign-c...
I'm not claiming anything other than a 15 minute familiarity with the situation here. I may have heard earlier rumblings but really haven't followed this at all and wasn't consciously aware of particulars.
Is it just incredible incompetence on WoSign's part or is there a stronger reason why China's largest CA is trying to keep issuing weak certificates? Is is tinfoil-hattery to assume that the Chinese government is not ready for SSL to start getting unreadable again?
I think this is all there really is to it. Some customers wanted to have backdated SHA1 certificates so they could continue supporting platforms that do not accept SHA256 certificates. WoSign decided to oblige them.
> This was caused by the CMS (Certificate Management System), when it sent the signing request of the certificate to the signing server A, which had no response, then the CMS sent it to the other newly added signing server B. After a while the signing server A signed the certificate and sent to the CMS and also to the subscriber, then the subscriber installed the cert in its website and hat's why Censys recorded this certificate; in the meantime, the signing server B also signed this certificate some time later (in seconds) and sent it to the CMS, the CMS accepted it and rewrote it in the DB.
> This issue happened after adding another signing server on Jan 5th 2015, and found it on April 9th 2015. When had the two signing servers added a load balancer, but the configuration was not properly done because it didn't lock the request.
Mind you, that's a perfectly legit technical bug. Maybe they were using nginx for load balancing POST requests? :)
So if I get it right, WoSign will cease to exist as a CA given the 1y probation proposed by Mozilla and the general distrust that will follow?
The WoSign roots were cross-signed by[0] Comodo and StartCom (owned by WoSign, but we didn't know that), so even with WoSign roots being revoked, there would still be a verification path.
Nice to see that now there is an effort to disclose all of these[2][3], and[1]:
> Mozilla now requires the disclosue of all intermedidate certificates, including those cross-certificates.
[0] https://wiki.mozilla.org/CA:WoSign_Issues#Cross_Signing
[1] https://groups.google.com/d/msg/mozilla.dev.security.policy/...
[2] https://crt.sh/mozilla-disclosures
[3] https://secure.comodo.com/products/publiclyDisclosedSubCACer...
