STE WILLIAMS

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.

CA danger

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 ucf.edu.

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 www.med.ucf.edu.

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 anaccount.github.com (and anaccount.github.io).

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 github.com, github.io, and www.github.io.

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?

Follow @NakedSecurity
Follow @duckblog

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/3HjklqIaZO0/