Just under three weeks ago, we wrote about a TLS certificate blunder by a Root Certificate Authority (CA) called China Internet Network Information Center, or CNNIC for short.
We thought we’d revisit that story today to see how the Big Four browser makers responded to the lapse.
First, a quick recap.
Root CAs are in a super-trusted position in the world of online security.
Generally speaking, operating systems and browsers trust Root CAs to vouch for other people’s secure websites.
Obviously, if you present an encrypted (HTTPS) website and invite your customers to entrust their credit cards to it, it’s not enough for you simply to say you’re Example Dot Com Trusty Trading – anyone could do that.
You need to get a CA to back you up with a digital signature on your security certificate.
And that CA needs to be a Root CA itself, so everyone’s browser trusts it, or to be an Intermediate CA, which means they’re backed up with a digital signature from a Root CA, so there’s a chain of trust “to the top.”
Often, Root CAs sign intermediate certificates for one of their own business divisions, which seems reasonable: it’s not an enormous leap of faith to assume that consistent policies, procedures, oversight and ethics pervade the company.
Sometimes, though, Root CAs sign for third party customers so that those customers can become Intermediates, and run a web certificate business themselves.
That’s good for competition and choice, but it means that Root CA who signs a certificate for an Intermediate CA had jolly well better be sure that the Intermediate CA is trustworthy and reliable.
The CNNIC story
That didn’t happen in the recent CNNIC story.
CNNIC signed a two-week Intermediate CA test certificate for an Egyptian service provider called MCS Holding.
MCS apparently intended to enter the business of providing “trusted public signing capabilities,” but during their testing, things didn’t go too well.
The Intermediate CA certificate ended up installed in an outward facing web filtering proxy.
You need a trusted certificate in a web filter if you want to intercept HTTPS traffic, because you have to decrypt the real site’s traffic to look inside it, then re-encrypt the traffic with your own certificate before handing it on to your users.
But you are supposed to make a certificate specifically for your web proxy, and then to tell your own browsers to trust it.
You are not supposed to take an already-globally-trusted Intermediate certificate and use it in your own web proxy just to sidestep the hassle of configuring your own browsers properly.
Doing that is considered an unacceptable risk.
That’s because anyone from inside or outside your organisation who managed to get access to your proxy server could steal the Intermediate certificate keys, and start minting globally-trusted certificates for anyone they wanted.
Such as cybercrooks.
Intermediate CA certificates are a bit like gold ingots: not to be left lying around in server rooms.
Why Intermediate certificates matter
What happened here is a bit like a country’s Reserve Bank (CNNIC in the story) authorising a banknote printer (MCS in the story) to print official currency notes…
…and then finding out that the printer has been running off a few extra official banknotes for internal use in the company canteen, “because everyone knows what they’re supposed to look and feel like.”
Obviously, the misused Intermediate CA certificate was revoked immediately by everyone.
It was set to expire in two weeks anyway, so the immediate danger was low.
But the incident did raise the question, “What to do about trust in CNNIC in the short term?”
The results are in.
CNNIC trust changes
Apple just updated its official list of Root CAs, known as its Trust Store, in the latest OS X and iOS updates.
The entry CNNIC ROOT kept its spot.
→ On OS X, go to Applications | Utilities | Keychain Access.app and look under System Roots.
Microsoft’s Root CA list isn’t populated up front; instead, trusted certificates are fetched as needed and then added to the list.
We took a fresh install of Windows 10 and browsed to https://cnnic.cn/, which produce no certificate warnings, and left us with CNNIC ROOT in the official list.
→ From Internet Explorer, use Internet Options | Content | Certificates and look in the Trusted Root Certification Authorities list.
On the other hand, Mozilla decided against CNNIC, describing the blunder with MCS as an “egregious practice.”
Certificates minted by CNNIC from 01 April 2015 or later will not be trusted by default.
Google, who spotted this whole kerfuffle in the first place when MCS’s dubiously-configured proxy showed up on the internet, took a similar line to Mozilla.
Google Chrome will keep trusting existing CNNIC certificates “for a limited time,” but the plan seems to be to ditch CNNIC as a Root CA altogether, until such time as “suitable technical and procedural controls are in place” in the CNNIC organisation.
Whither the chain of trust?
This whole incident shows just how complicated – and not only for technical reasons – the TLS chain of trust has become.
The Big Four browser makers are split fifty-fifty over whether to continue trusting CNNIC, or whether to send the company to the Sin Bin for a spell.
Even Mozilla and Google, both of whom reached for the red card, did so on slightly different terms.
Mozilla won’t honour any CNNIC certificates signed after 01 April 2015.
Google will do the same, but with a brief amnesty so nothing breaks.
And there’s part of the problem: there are so many chains of TLS trust in our ecosystem that even two of the biggest browser makers, Google and Mozilla, aren’t willing to risk pulling the plug on all CNNIC certificates until further notice.
You can see why.
If major sites with CNNIC-signed certificates suddenly start popping up certificate warnings all over the world, users will quickly adapt to the bad practice of trusting those certificates anyway.
So, why take any action at all?
After all, CNNIC’s blunder turned out to be neither critical or particularly dangerous.
On the other hand, neither is drink-driving if you happen to make it home from the pub without meeting any other vehicles or pedestrians, and without running into a hedge along the way.
The answer with drinking and driving was to establish a statutory offence based on the percentage of alcohol in the breath or blood.
That way, the actual sobriety of drivers didn’t needn’t be tested, nor the quality of their driving be evaluated and argued about, thus removing subjectivity from the equation.
If you blow over the limit, you are over, and that’s that.
Your actual level of drunkenness or impairment, if taken into account, can only increase your offence, and never excuse it.
But quite how we reach that sort of enforcement attitude in cryptography, I’m afraid I can’t tell you!
Katie
Great analogy at the end! Lol
Jim
You asked “But quite how we reach that sort of enforcement attitude in cryptography, I’m afraid I can’t tell you!”
Perhaps use the same process: choose a percentage of traffic, beyond which they’re “impaired” until they “sober up”.
In other words, once untrustworthy certificates from a CA show up as trusted in X% of the worlds servers (counted as a statistical sampling, not a raw count), the whole CA gets marked as untrustworthy until they fix the problem.
I’m not sure what X is, and I think there would need to be a layered approach. But, it seems that a standards body could establish a value for X (and perhaps Y and Z as “warnings”), and ask the major browser vendors to honor it. Since CAs can revoke their own certificates, hitting a warning level (Y or Z) should be enough incentive to correct the problem before X is reached.
loadtest
Perhaps more worrisome than CNIC is the certificate right below the one highlighted in the screenshot. The innocently named “Common Policy” has an issuer named “US Government”.
I wonder why they didn’t put their name on the certificate like everyone else. In any case, they can mint their own certificates (when they run out of Realtek’s.)
testing
It’s awesome in favor of me to have a site, which is useful in support of my know-how.
thanks admin