A spot of cryptographic bother is unfolding in Mozilla’s security policy discussion forum at the moment.
It’s one more thing to worry about when someone asks you, “How do I know when to trust an HTTPS certificate?”
HTTPS is the protocol that puts the padlock into your browser’s address bar, and it does two equally important things:
- Keeps your HTTP browsing secure against snooping and modification. Even if all you are doing is reading Naked Security, that’s no one else’s business.
- Gives you confidence you’re on the right website. An encrypted connection is no use if you’re talking to an imposter at the other end.
In cryptographic language, that gives you confidentiality and integrity, meaning that the data you see is both private and correct.
Very greatly simplified, HTTPS uses an encryption protocol called TLS, short for Transport Layer Security, and it works roughly like this:
- Your browser connects to a server, which sends back an encryption key to use for confidentiality and a digital certificate to vouch for its right to run the site you’re visiting.
- The certificate is digitally signed by an organisation called a Certificate Authority (CA), which vouches for the first company’s claim to own the website site you are visiting.
- The CA is vouched for in turn by your browser or operating system, which ships with a list of CAs that are already trusted to vouch for other people.
(There my be more than three steps up to the browser’s built in trust list, but the idea is the same: a chain of trust exists that is supposed to give you confidence in the authenticity of your connection.)
You can see what the TLS chain of trust looks like in an earlier article we wrote about a certificate blunder made by a French CA.
A rogue CA, one that will sign certificates with its own trusted-by-all-browsers root certificate while knowing them to be false, is an obvious and significant danger to the entire internet.
But sloppy CAs can cause just as much trouble if their certificate signing process is riddled with errors, and that’s what has led to the brouhaha in the Mozilla community right now.
The slapdash CA in this case is a Chinese outfit called WoSign, and the problems exist with its free certificate-issuing service.
Signed TLS certificates that vouch for other organisations are supposed to involve some sort of check that the applicant has the right to make the request, to prevent just anyone acquiring a certificate with which they can pretend to be running someone else’s site.
If there were no verification at all, crooks could easily get hold of a certificate identifying them as the legitimate owners of a financial website; at this point, they could run a phishing attack by means of a fake site that was apparently “certified” to be the real thing.
Free certificates, which are considered an important part of helping website owners who otherwise wouldn’t bother with HTTPS to start using it, don’t involve enormous amounts of checking (they’re free of charge, after all), but they’re nevertheless not supposed to be a free-for-all.
The problem with WoSign’s automated certificate checking was that it was plagued by a bug that showed up by mistake.
A WoSign customer wanted to acquire a certificate for the server name
med.ucf.edu, a subdomain of the University of Central Florida’s domain
The customer was duly authorised to run this subdomain, which belongs to the College of Medicine, so WoSign was correct to approve it.
However (and, in hindsight, by good fortune), the customer also accidentally applied for a certificate for
www.ucf.edu, presumably having mistyped
To his surprise (I am guessing at the customer’s gender here), the second application was approved as well.
This turned out to be more than just a one-off, because the customer did a second test, using a certificate in the name of another domain he had the right to control, namely
Deliberately following the same faulty path that he had followed by mistake in his previous application, he ended up with a vouched-for certificate for all of
As these are the primary server names for the popular source code hosting service GitHub, this would have been a blunder with serious consequences if a crook were to have spotted this trick and acquired the dodgy GitHub certificate with cybercrime in mind.
This all happened a year ago.
Repairing the damage
WoSign quickly revoked the dodgy GitHub certificate, which was a good start to repairing the damage, but a CA needs to do more than that to convince the community that it has sorted out its sloppiness.
The CA really needs to show, after a blunder, that it can identify all the side-effects of the blunder and deal with those too, and that it won’t repeat the mistake.
A year later, however, the incorrectly issued
www.ucf.edu certificate apparently still hadn’t been revoked, even though it was obviously caused by the same sort of error that led to the bogus GitHub certificate.
The customer who’d reported the GitHub problem back in 2015 probably assumed that WoSign would not merely paper over the cracks by revoking that one certificate, but look for others issued by mistake due to the same bug, and deal with those too.
Mozilla security experts also expressed concerns that WoSign never reported this bug to the TLS community, as it ought to have done, or declared that it had issued incorrect certificates.
Worse still, Mozilla became aware of other blunders made by WoSign (you can read about them in the Mozilla forum) that weren’t reported either, and which still don’t seem to have been taken seriously enough by the CA.
What to do?
The answer seems obvious: remove WoSign from the list of trusted root CAs.
But this is not a step that the TLS community takes lightly, not least because of the knock-on effect on other users, whose correctly-issued WoSign certificates will suddenly start kicking up certificate warnings in everone’s browser.
As a result, the Mozilla team is still undecided:
Taking into account all these incidents and the actions of this CA,
Mozilla is considering what action to take. Your input is welcomed.
What do you think?
18 comments on “How one man could have owned GitHub, and what happened next…”
“Even if all you are doing is reading Naked Security”
har. I can think of far more fallow and fruitless ways to consume time via the interwebs.
No doubt it’s a labyrinthine process to add or remove a CA from the club–not that it’s entirely a bad thing as it should not be trivial for me to decide this morning I want to become a CA.
But if any system is not supported that system will fail. A CA should absolutely be excommunicated if they can’t can’t rapidly right their wrongs and document quite publicly that it’s being done.
I routinely review Mozilla’s list of trusted CAs and remove those that I don’t trust. Why would UCF need to go to a Chinese CA for a cert? Stick to the sidewalk…
Presumably the administrator of the med subdomain (note that it wasn’t the admin of the ucf domain) was looking for a CA that would issue free certificates relatively easily, which is what WoSign provides. The location of the CA is not really the issue – their ability to correctly issue certificates is.
The average web user doesn’t pick which CAs to trust. Their browser does this for them. In essence, when browsing with Mozilla browsers, we are trusting Mozilla to make the right decisions for us and, by extension, Mozilla is trusting the Certificate Authorities to make the right choices.
The hierarchy of trust for SSL certificates places extreme consequences at the CA level. It should not be easy to get into a position to be a CA and maintaining your position as a CA in the major browser’s default trust list is a big responsibility. If Mozilla maintains WoSign in their default trusted CA list, that’s a statement that Mozilla believes WoSign is trustworthy. Personally, I have doubts about any organization that makes repeated mistakes and doesn’t own up to them being included in this small circle.
This basically boils down to the following:
is there any incentive to check, or penalty for not doing so?
Are their any fines or penalties for this type of irresponsible behaviour, mainly for not reporting this and other issues?
This could be dangerous as I think the vast majority of users still look only for the https in the url bar and do not actually check who issued the cert and the details, as many sites are too cheap to pay for an EV level cert. Lets hope that letsencrypt starts to offer EV level certs someday 🙂
The general feeling that I get is people see a green ssl cert and https, and assume that means the website has been secured, and verified, which is ultimately not not the case
The conversation usually goes like this “but i saw the https in a link from google, so that mean it should be trusted right ? I thought the S was for Secure…
I wish HPKP could be auto integrated with letsencrypt, as this would offer a free route for users to guarantee some authenticity. A web site operator could effectively reduce the set of issuers that can issue for their site, without Balkanizing the web.
Just goes to show that centralized CA were a stupid idea. No single person or company should have the power to authenticate as every other digital entity in the world. It’s a textbook example of a single point of failure, created out of laziness because no one, at the time, could come up with a good decentralized certification design.
It isn’t clear whether WoSign have corrected their bug. If not, now that the crooks know the problem exists, I see no alternative but to remove WoSign’s authority becaue the damage that could arise very quickly would be very much more serious than the inconvenience of having WoSign’s certificates ‘kicking up’.
Revoke the root cert. If a user wants to bypass the warning, so be it. The systems trust is of paramount importance. Otherwise we are calling the root list untrustworthy. Then the whole system might as well be scrapped.
This time it was GitHub where lots of intellectual property is stored. Next time it might be a bank where money is stored. It seems clear that WoSign has decided to simply hide the problem instead of fixing it. They should not be trusted.
I do not profess to understanding the certificate process to any great length but I certainly would ultimately revoke the trust of the CA. I understand that we cannot know and hope to pre-warn visitors to sites signed with a WoSign certificate what the situation is but it should be possible assuming proper customer records are kept to contact all customers of WoSign and get them to make alternative arrangements for certification, maybe issue a grace period and then revoking trust after that period.
Is this issue only with Firefox? I just removed the WoSign CA certs from firefox, but I cannot see them in Chrome
How can anyone have any faith in the CA system if breaches of the rule don’t have consequences?
This CA literally put the enture internet at risk, and it looks to me like they simply do not understand the mangnitude of their failings.
I can’t beleive there is any debate about whether or not a CA like this should be removed from the browser. Any chain is only as strong as its weakest link, and this link looks extremely weak to me!
Simple, remove WoSign.
No other option in my opinion. They simply have not earned our trust.
The key word here is ‘trust’. WoSign have clearly demonstrated that they can’t be trusted. That’s the bottom line.
As Mozilla CA’s are included in their update packages, I would suggest that they could also include a “start page”, much like the welcome page, in the next version to inform all users that as of a set date and time WoSign will no longer be trusted by Mozilla. At that time, patch WoSign out.
There are other more trustworthy, free, CA’s in the marketplace.
I have removed all WoSign CA certs from Firefox on my PC. I wonder how many sites with their certificates (now inaccessible) I will stumble across in the future…?
Please post here if and when you do…interesting to know what difference this makes if you aren’t in China.