> 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?
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 only recently found out that anyone that can reliably man in the middle your server can get a valid HTTPS cert from CA's like Let's Encrypt. That includes cloud providers, backbone providers and possibly the local government where the server is located. [edit: It also includes anyone that can temporarily modify or spoof your DNS records.]
The CA/Browser Forum has endorsed a variety of ways of proving control over a domain; for each of them, if some CA uses it and you can spoof it, you might be able to get that CA to misissue a cert for that domain.
The desire to somehow tighten this up is in tension with the desire to make HTTPS ubiquitous, and an underlying problem is that we're on the Internet where there is no central identity mechanism or source of proof of identity assertions -- except perhaps the DNS root and all of its associated registration and delegation mechanisms.
Maybe someday we could slightly clean up DV by making the proof of domain control go through DNS domain registries, since they're the underlying source of authority or ground truth in the DNS system right now. We could imagine a protocol where a CA has to ask the registry whether a particular certificate request is really from an entity that the domain registrant has approved, and both the CA and registry could publicly log the question and answer. (Perhaps we'll also have certs for other kinds of naming systems as well.)
In the meantime, you can make a CAA record, use HPKP, like pfg said, and check the Certificate Transparency logs. None of those are perfect, but they're a lot better than what we had with DV five years ago.
Or maybe registries could directly act as CAs for their own TLDs (and no others). It would be an interesting discussion about how this would be better or worse than what we have now.
I imagine a lot of registries wouldn't want to pay for the infrastructure to do this, but maybe it should be regarded as a basic part of their role. Right now it would be very annoying because you could no longer get a cert for multiple names under different TLDs, at least if they were managed by different registries (so you couldn't get a single cert covering example.io, example.cc, and example.net, even if you controlled all three names). Maybe if SNI becomes more ubiquitous this limitation will seem less annoying in the future.
What I was suggesting above was having domain registrars or registries use a new protocol (not DNSSEC) specifically to authenticate domain registrants to CAs for improving the security of DV certs -- and in order to replace existing DV mechanisms. My thought is that registries and registrars together possess the ground truth about domain ownership in the DNS system, and so it would be helpful if they had a way to securely communicate that directly to CAs. I didn't mean to suggest that DNSSEC should be that way.
I don't think this would be vulnerable to any of Thomas Ptacek's particular criticisms of DNSSEC, unless the first section implies that he wanted to completely eliminate DV certs or stop trusting them as a general matter. I didn't read it that way. However, we might take the article to imply that DV certs, even if they could be guaranteed to match up perfectly with the DNS ground truth at all times, may never be enough as the main or only means of authenticating some entities for some purposes, which is also fair.
That'd at least mean an attacker would need to be MITMing the connection close to your server/loadbalancer instead of near to the CA?
Wouldn't help if someone was doing a Quantum Insert style attack from within your hosting infrastructure. (I wonder if there's pre-build AMIs to let you quickly spin up open source implementations of Qantum Insert on AWS already?)
In general, you are going to be MITM'd near your endpoint (ISP level DNS tricks, or on your WiFi) or near the destination endpoint, very rarely somewhere in the core (although that has happened with some BGP hacking). To prevent the client being mitmd you can ask something else on the internet what their cert resolution chain was.
If the server can be mitmd with a valid cert the only solution is for all clients to contribute to a distributed consensus -- appending the cert chain they see to a distributed log.
Most CAs that operate today are located in countries where mechanisms exist that could very well be used to force a CA to hand over private keys and/or sign certificates, not to mention that some intelligence agencies (or other actors) might use not-so-legal means to achieve the same thing. So why bother trying to enforce some kind of "NSLs (&co.) are bad unless you're one of The Good Guys" rule rather than embracing a mechanism that guarantees that CAs will be caught when they engage in such behaviour (willingly or not)?
The WoSign roots were cross-signed by 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, and:
> Mozilla now requires the disclosue of all intermedidate certificates, including those cross-certificates.
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?
CloudFlare made a deal with Comodo to issue (non-backdated) SHA-1 certificates from a "legacy" root that is mostly no longer trusted by modern clients.
Symantec and Entrust are also issuing SHA-1 certificates from "legacy" roots to large enterprises.
That's quite a nice solution.
The upside seems to be there's very little additional risk if certs are issued that "modern clients" won't accept - while still allowing "legacy clients" to commuicate with the level of security/encryption they always have.
I guess the downside is - allowing it to contniue means nobody will _ever_ upgrade or turn off "legacy client" equipment - which is probably all riddled with huge numbers of other "known exploits"... If you make it possible to put off upgrading your WindowsXP (or equivalent early 2000's linux based) POS system or industrial/SCADA gear - it'll stay around randomly switching which botnet it's DDoSing for forever...
Once a root certificate has been pulled from a root program, they stop being in scope for the root program policies and the Baseline Requirements (at least that's the common interpretation), which would prohibit SHA-1 issuance from those roots. There's been some discussion about changing this.
(Symantec accidentally signed a SHA-1 certificate from a publicly-trusted root while preparing their SHA-1 issuance exception application, but that's not quite as bad, I guess.)
It would be a lot more justifiable (and far better for everyone involved) if, for example, the SHA1 certs through Comodo’s pulled root were available to everyone.
I don't want to pick on Cloudflare or Comodo right now (see my other comment in here), but if someone were to propose a rule change that says a CA's trust obligations extend to all their old retired trusted roots as well as their current and future ones, I'd be inclined to agree unless I heard a very convincing argument against it (that had some strong protections in place to stop some of the obvious abuse possibiulities).
Thought experiment: what'd happen to a CA with root trust, if they negotiated to update a root cert, replaced their old one in all the trust stores, then sold their old private key to $badpeople?
Obviously, all these options are not available to anyone except a handful of large companies.
Edit: The exception processes also do not involve fraudulently backdating anything. Which is kind of a big deal when you are in the trust business.
EDIT: Was reading out of date info :)
~~However like some one else pointed out out of the discussion in the group looks like it was a technical bug, which is still bad, but at least not maliciously bad.~~
Gah HN why you still no do markdown....
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)
"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
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.
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.
Also out of curiosity: How many languages that are not related to your native language can you fluently read?
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.
Also do you honestly think that was written by the business team, do you think the business team would have been able to properly edit a technical document in another language?
Seriously you'll be hard press to find a paid translator that can translate technical documents.
Also the document is actually reasonable coherent. Picking on the language level of the document over the technical content of the document seems kind petty.
You'd hope they'd have a good technical translator already on their payroll.
Japanese is one. I've many times read comments written in Japanese in the Ruby language source code and understood their meaning, but there is absolutely zero ability for me to visit that country and be able to interact with anyone.
The author of this incident report is leagues more capable than I am in writing a report in a foreign language. They didn't insult my mother, or my dog, or call me names by accident. I don't see the justification in insulting their English.
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.
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.