Certificate Authority Gave Out Certs For GitHub To Someone Who Just Had A GitHub Account
from the oops dept
For many years now, we've talked about the many different problems today's web security system has based on the model of security certificates issued by Certificate Authorities. All you need is a bad Certificate Authority to be trusted and a lot of bad stuff can happen. And it appears we've got yet another example.A message on Mozilla's security policy mailing list notes that a free certificate authority named WoSign appeared to be doing some pretty bad stuff, including handing out certificates for a base domain if someone merely had control over a subdomain. This was discovered by accident, but then tested on GitHub... and it worked.
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.As you can imagine, this should be a cause for quite some concern:
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.Mozilla also noted that WoSign never informed it of the earlier misissuance either. This is a pretty big mistake. The Mozilla post also calls out some questionable activity by WoSign in backdating certificates, but this first point is the really troubling one.
I recognize that until a better system is found, certificate authorities issuing certificates is about all we have right now for web security -- but, once again, it really seems like we need to be moving to a better solution.
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: certificate authority, https, security, ssl, subdomains
Companies: github, mozilla, wosign
Reader Comments
Subscribe: RSS
View by: Time | Thread
Commerical CA
Seriously, you can pay assloads of cash for an EV Cert and for fucking nothing more than a few bits of encryption.
The idea that a 3rd party should be default trusted on any computing platform is the same as pulling your fucking pants down every time a rapist walks by. You are just fucking begging to be rapped! Every commercial CA has spies in them, and for very fucking damn good reasons!
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Perfect solution right here.
[ link to this | view in chronology ]
Re: Perfect solution right here.
[ link to this | view in chronology ]
The root problem
This is all in the name of making a "positive user experience". No, I can't explain to my grandmother how to choose what certs to trust and what certs not to. It's a kludge and always has been.
[ link to this | view in chronology ]
Bitcoin has seen some concentration of decision power in the hands of the Chinese where the biggest coin farms reside so this could be a problem. Or not since there is nothing to farm. I'm not really an expert here so I'm only wondering.
In my opinion based on what I know it could be feasible.
[ link to this | view in chronology ]
Re:
https://www.certificate-transparency.org/known-logs
the problem is that some Certificate Authorities have such a HUGE number of certificate issued per month (e.g. LetsEncrypt) that they are banned from publishing new data to the logs.
[ link to this | view in chronology ]
Re:
Nothing to farm? If anything, the incentive is exponentially greater here.
Bitcoin is a fraud-plagued mess of a fringe currency experiment that's losing more and more prestige with each passing day. But put something of real value on the line, like the security of the fundamental infrastructure of the Internet, and you paint a massive target all over the entire system!
[ link to this | view in chronology ]
Re: blockchain based certs
[ link to this | view in chronology ]
You can sign your certificates with your own crt and do not need to fully relly on your CA. You always have the last part of the key.
[ link to this | view in chronology ]
Re: HPKP
DNSSEC has a nice feature called DANE, using TLSA records with the hash of your SSL certificate. Browsers can check the integrity of your DNS responses as well as the SSL certificate offered using the same infrastructure!
[ link to this | view in chronology ]
Re: Re: HPKP
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]