Google pulling China CNNIC CA from its products
googleonlinesecurity.blogspot.com
googleonlinesecurity.blogspot.com
Ex: http://en.wikipedia.org/wiki/Comodo_Group#2011_breach_incide... Nothing happened after this breach, which was a shame.
The above link should work. This will teach me to link to an anchor on Wikipedia.
[original post] It should have been: https://en.wikipedia.org/wiki/Comodo_Group#Certificate_hacki...
The whole system is worthless and it should be replaced with something more like bitcoin. I don't really trust any certificate issuer more than I trust self issued certificate.
What does that even mean?
Perhaps Google might want to sponsor this? :)
I guess we'll eventually get there, but unless we get decentralised I don't see how it could be done.
Honestly I have no idea how the current system is purported to work. And I just don't know what certificate is supposed to prove? That someone at some point in time had 100$ to spend on a cert? How's that more secure than self signed cert?
Why browser warns about self-signed and not about others? All thing seems to me to be more of a security theatre and money making scheme than actual trust system that reflects reality in any way.
I agree that the current system is broken, but I fail to see how a distributed system magically fixes this, most notably the issue of bootstrapping trust. I foresee that the distributed model moves to a more centralized model where we trust apple, microsoft, ubuntu.
Bootstrapping trust should start from entities that actually have information about identity.
Also information about identity should be explicit and carried through the system. What happens now for me looks like bunching together good and toxic assets and creating derivatives. Creating something that to general to fail.
Some people in comment refer to previous incident that didn't have any repercussions probably because it would have too many consequences.
One outstanding problem that comes to mind is certificate revocation when you have lost control of the private keys. I think a multi-sig solution could probably mitigate this to a fair extent, so you still have some level of pseudo-trust between entities and a way to effectively call someone up and say, "hey, I screwed up and need to kill this thing".
There is value in a higher barrier to entry. That much is seen in almost every place that has such barriers. Nintendo games are typically high quality and App Store apps are usually not (and Play Store -- not picking on anyone). I've seen much higher quality from sites hosted by regular hosting companies (and paid-for domains) than I do from sites like mysite.site99.commish.ru (if you'll excuse the exaggerated example). Self-signed is even worse than my exaggerated example when it comes to trustworthiness because there are far too many bad actors who want to do bad things but also don't have $100USD to spend on a cert. I don't doubt that some kind of better system can exist but self-signed is definitely less trustworthy.
I think that only government that issues my ID is the only party that can confirm my identity, so it, rather than private corporation should sign my cert only after it verifies my identity in the same way it would if for example I would testify in court.
If I wan't to associate cert with a company, only the office that registered my company can provide meaningful assurance about identity of my company.
The security of the system for propagating this assurance of identity of entity should not rely in any way on authority of any entity, public or private.
Also the assurances should be explicit. If someone confirms that I paid the utility bill for given address should only say that they confirm that I did that, not that I live there.
A standard domain-validated cert proves that the CA saw you as in control of the site's DNS. Because spoofing DNS for client machines is generally much easier than for servers this is a big improvement in security over a self-signed cert.
After a short, limited grace period, Google won't honor the recently compromised Chinese CNNIC CA cert anymore, and won't reconsider until they implement Certificate Transparency.
We really need a "zero tolerance" system for CAs: As soon as you fuck up, you're out. There has been too much forgiveness and too little enforcement so far. Browser vendors, especially those with deep pockets such as Google, Apple, and Microsoft, should not be afraid to leverage their influence to make rogue CAs go out of business. Seriously, there are too many CAs already. 90% of them need to go bankrupt asap.
We also need some way to restrict what certificates "less trustworthy" CAs can sign. Even if CNNIC is one day reinstated, I wouldn't want them to sign any certificate for any domain that doesn't end with .cn. Ditto for various other government-sponsored CAs, which my browser also seems to trust for whatever reason. Even if TLS as we know it has no mechanism to enforce such restrictions, nothing stops browsers from doing it on their own.
You would have no CA's then. I love when people criticize others without offering a anything in return.
Of course, you can reapply to get in (haha, good luck getting a response from Mozilla before a couple of years) but you have to start from scratch all over again. This puts a tangible cost to shenanigans. I highly doubt Verisign would be caught making the mistake these guys did.
http://www.reuters.com/article/2012/02/02/us-hacking-verisig...
Sure, everyone makes mistakes. And if you're in the business of trust, you find ways to uncover and correct those mistakes. Also, you insure against those mistakes, and some of that insurance buys another set of eyes.
If the requirements for becoming (and remaining) a CA become stricter than they are now, the market will adjust after a while. Peace of mind has always been, and will always be, a very strong selling point. How about this: "We'll sell you three certificates for the price of one! One signed by Comodo, one signed by Verisign, and one signed by GlobalSign! And here's an Apache module that detects when one of your CAs get discredited, and automatically replaces it with a good one!"
https://tools.ietf.org/html/rfc6066#section-6
You could imagine a variant for, say, pointing out that you explicitly distrust certain CAs that the server is likely to assume you trust.
"certificate_list
This is a sequence (chain) of certificates. The sender's
certificate MUST come first in the list. Each following
certificate MUST directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate that specifies the root
certificate authority MAY be omitted from the chain, under the
assumption that the remote end must already possess it in order to
validate it in any case."
Would you? We've seen, what, a dozen (at most) CAs do inappropriate things in the last several years? And there are hundreds of CAs? I think things would be fine.
In particular, there are lots of intermediates. My personal website's cert is from Gandi, which uses an intermediate chained off USERtrust. Gandi could arrange to have a second root CA sign their intermediate, so that if USERtrust gets kicked out, browsers can still construct valid chains. And I would gladly pay for such a feature from an intermediate, if the alternative were either my site being at risk of being marked untrusted, or SSL becoming meaningless.
Aren't you asking for "name constraints" to be enforced? If they could do this, they could fix the whole CA fiasco, but actually delegating domains rather than have a system where Root CAs are trusted for all domains.
It does exist. Now do I trust the existing certificate validation code to do the right thing in all cases in presence of the extension? Not one second.
Until a couple of hours ago when I manually went through my browser's CA list, there were a lot of national and even subnational government agencies in there. Japan, Taiwan, South Korea, Catalonia, Valencia, and even Hong Kong Post has its own root CA.
Let's assume, and this is not unlikely, that your favourite three-letter agency in is possession of a handful of trusted CA keys, acquired with extralegal methods.
What happens when there is leak? This may be the result of a whistleblower, or some mistake somewhere, which leads us to have a stronger confidence that these keys are out. Do we still blacklist? Only the intermediary, or all the way up to the CA?
I think we've seen from the past years that both root and intermediaries can follow every rule in the book and still get owned by intelligence agencies. We simply cannot pretend this is unacceptable for doing business.
I think that this is a great reason to have zero-tolerance policy to CAs fuckups.
Browser vendors publicly announcing a zero-tolerance policy would effectively be a warning to the governments of the world: "Do not fuck with our PKI, or else." This will have far-reaching consequences even before any CA officially gets banned.
That would create an even bigger incentive than today to cover any misuse up. Not sure that's what we want.
When every browser ships with verified fingerprints for a lot of important websites, it will be nearly impossible to use fraudulent SSL certificates on any significant scale without triggering a worldwide alarm.
Chrome already reports home when it encounters a forged certificate for any Google property. Firefox has started to use Chrome's HSTS preload list too, and Microsoft said they would use it in IE & Spartan on Windows 10. The future isn't looking good for would-be certificate forgers.
> 1. The decision that Google has made is unacceptable and unintelligible to CNNIC, and meanwhile CNNIC sincerely urge that Google would take users’ rights and interests into full consideration.
> 2. For the users that CNNIC has already issued the certificates to, we guarantee that your lawful rights and interests will not be affected.
Deciding to not let a company, with the ability to MITM users worldwide, that did not have systems in place to avoid misuse, continue to have that ability?
They also seem to be under the conception that they're in a position to accept or not accept the outcome. That's now this works.
If only CNNIC took being a CA as seriously as they do writing angry press releases.
Correcting self: that's /not how/ this works.
Standard language of the authoritarian mindset, everywhere.
How does this work, e.g., on systems which install root CAs from standard packages? I think you'll find you'll need to 1) re-run the script and 2) that you're not getting the benefit of retaining the root but flagging it as untrusted.
I just posted on flagging the CNNIC root as untrusted in Debian. That's better than deleting the CA, as it should now show as negative trust if I'm grokkign things properly.
It's not intended as patch or fix for the CA system which is broken by design - merely something that I was interested in trying.
We need to send CAs a strong signal that the trust (and license to print money that comes along with it) we put into then hinges on them behaving properly. Making sure that their intermediaries do the same is obviously part of the deal.
We must make it very clear to CAs that hiding behind intermediaries is not an acceptable strategy to escape their responsibilities.
I'm only mildly supportive of Certificate Transparency, but would definitely like it to "have its day in court." Hopefully CNNIC deploys CT and reapplies to Google for inclusion, but either way it will be interesting. I love it when things get put to the test.
What are the odds they'll do this? I'd bet extremely high.
I don't understand why this would be allowed. Like, doesn't this break the entire concept of a CA if the CA will allow third parties to issue certs? I understand the need for corp MITM but that's best done by pushing out your own CA. And I understand the desire for a company to have its own self-managed CA system that's publicly trusted. But that simply cannot require the CA to put any trust into the other company; there's gotta be technical measures. That's why I'm confused as to why it matters if an HSM was used or not. Can someone enlighten me on what's going on?
Personally, I think I should trust the hardware or OS manufacturer to pick exactly who is trustworthy enough to certify websites, since I'm trusting them that my computer is doing what it looks like it's doing anyway.
No, CNNIC is not even trustworthy among Chinese Internet users.
CNNIC invented tons of rootkit adware and spyware. It has a very bad reputation. Google for 3721 中文网址 if you are interested
Although it claims to be a neutral non-profit organization, it does have multiple for-profit business lines.
In the past CNNIC belongs to China Academy of Science, but now it's just a puppet under ruling Party's control[1][2].
[1]: http://en.wikipedia.org/wiki/Central_Leading_Group_for_Inter...
[2]: News in Chinese http://tech.gmw.cn/2014-12/27/content_14311910.htm
CNNIC is not trustworthy especially among Chinese Internet users.
Oh? Then why did Firefox, Google, Microsoft, Apple, etc. trust their root certificate? I know hating on China is all the rage, but something isn't making sense here...
> Google for 3721 中文网址 if you are interested
Just did. Got nothing. Are you referring to [1]? I'm not seeing what that has to do with CNNIC.
Mozilla no longer trust CNNIC.
https://blog.mozilla.org/security/2015/04/02/distrusting-new...
In particular, was there any evidence of any mis-deeds by the CNNIC before what MCS Holding did? Anything at all aside from "they are a Chinese and that is bad" FUD? Have they ever issued a certificate used to MITM the communications of political dissidents, for example?
[1] http://tools.ietf.org/html/rfc5280#section-4.2.1.10
[2] https://www.mozilla.org/en-US/about/governance/policies/secu...
Validation of x509 certificates is ridiculously complex, and CA rightfully only use the widely interoperable subset of extensions...
See for example http://blog.codekills.net/2012/04/08/adventures-in-x509-the-... about what really happens when one steps outside the well traveled path of certificate attributes...
Speaking from personal experience, writing code to correctly validate x509 certificates isn't as hard as it looks.
The fact that OpenSSL did it wrong for 15 years doesn't bode well for the myriads of TLS implementations that are around.
My experience with the x509 part of SSL/TLS stacks is really not good when you start to use something else than OpenSSL/NSS (well PolarSSL is pretty good too). Quite often there is enough implemented to interoperate in the common use cases, but you're on your own if you need a complete standard support... Then it has been a while, maybe it's a lot better now.
Source: I wrote all that code in Mozilla's implementation.
The claim from CNNIC was that the intermediate CA would only be used for domains actually managed by MCS Holdings; however, there's no technical control in place to ensure that, even if you believe CNNIC didn't know exactly what the intermediate CA would be used for.
What went horribly wrong is that nobody knew what they were doing, CNNIC didn't realize they had an obligation to bring in auditors to both CNNIC and MCS to make sure that people knew what they were doing, and MCS unintentionally placed the cert on a device that happens to do real-time SSL MITM.
I believe CNNIC's claim is about the "test" certificate that was issued to MCS. (The fact that they issued a test certificate off of a publicly-trusted one is another sign they didn't know what they were doing.)
There's a long thread on mozilla.dev.security.policy with replies by CNNIC and MCS that explains the story. (The CNNIC rep's English is pretty good, MCS's is good enough to get a sense of things.) https://groups.google.com/forum/#!topic/mozilla.dev.security...
That's right up there with "unintentionally loaded a gun, drove to the bank, held it up at gunpoint, and left with bags full of cash", and about as believable. If it really was unintentional, then it's still a level of incompetence sufficiently indistinguishable from malice that it should be treated as malice.
Maintaining certificate security is the primary job of a certificate authority. A certificiate authority that utterly failing to do so should be removed from the trusted CA list, as has occurred here.
While I'd like it if it that were the case... did you see the PDFs that I linked elsewhere in this discussion thread, that CNNIC originally posted to mozilla.dev.security.policy?
https://pzb-public-files.s3-us-west-2.amazonaws.com/B2.pdf
I can see the following series of incompetences as entirely too plausible:
- MCS happens to have some multi-function Palo Alto devices, because they're reasonable devices to have for a network operator.
- Palo Alto ships real-time SSL MITM capabilities (i.e., loaded guns) in their products, because lots of customers want them for use with internal CAs.
- Palo Alto is also a FIPS-compliant hardware crypto device, because thanks FIPS.
- MCS and CNNIC both vaguely know that intermediate certificates should only be kept on FIPS-compliant hardware crypto devices. They don't know why, they just know it's what people do.
- MCS looks around, sees the Palo Alto device, decides it's the right sort of device to use, and clicks the "Generate a CSR" button and sends it to CNNIC.
In any case I certainly agree that this deserves CNNIC removal, even if everything CNNIC and MCS has said is true (they're both admitting to gross negligence that failed at the most basic tasks of a CA, even if there was no malice in a strict sense). And also deserves MCS or any suspiciously similar organization being blacklisted by all the other CAs if they come asking for an intermediate.
Like, if it weren't for the hardware crypto requirement, it sorta sounds like MCS would have happily run `openssl req` on some developer's machine, and CNNIC would have happily signed it with their globally-trusted CA cert. Which would not have set off Google's tripwires, but would also have been completely unacceptable.
And I would agree: if a CA is delegating trust to another wannabe CA who is so ignorant, that CA is also negligent and should also have its cert yanked.
The explanation that the delegation was just so that MCS could MITM their own computers is also strange; as Google notes, the normal behavior for such a proxy is to set up your own signing infrastructure and push out your own CA to all machines under your control. Delegating the ability to generate certs for any domain and saying "but dont use it!" is utterly irresponsible.
Theres also a degree of deserved paranoia here; this is CA based in a country that is well known to target Google (as they are the one major search provider not cooperating with the Chinese government), who just happens to accidentally delegate CA rights to an org who accidentally generates certs for Google. Alarm bells are ringing.
The poor English doesn't inspire a lot of confidence in the company. I realize the company is from an area of the world that is not generally English-speaking, but geez, to respond to something as serious as this surely you can run your blog response by at least one native speaker to sanity check it before posting it.
But worse than that is the story they are seemingly trying to sell is that this is one random dude's fuckup -- which may very well be true, but that this could happen as the result of one random dude's fuckup speaks volumes about lack of much-needed process to deal with this sort of certificate responsibility.
I wouldn't be surprised if they did give it to someone who they thought spoke English well.
You should see sandwich menus. I was saying, English correction per word, if people saw the value, would make me a successful small business owner in about 3 years. Haha.
https://pzb-public-files.s3-us-west-2.amazonaws.com/B2.pdf
https://pzb-public-files.s3-us-west-2.amazonaws.com/B2.pdf
The story is perfectly believable: MCS wanted to become a CA, the easiest CA that would chain them an intermediate was CNNIC, they generated the cert from a Palo Alto Networks device because it was the only convenient hardware/FIPS-compliant device they had lying around, and a technician accidentally plugged their laptop on the "MITM me plz" port of the Palo Alto box and fired up Chrome, which automatically sent some alarm bells.
Honestly that makes me more worried for the state of internet security than active malice. If any individual, organization, government, etc. were intending to MITM someone, we could (in theory) track them down and fire them, blacklist their root, or otherwise expel them from the internet community. But nobody had such an intention here. It's terrifying that a series of honest mistakes (extremely grievous mistakes, but honest ones nonetheless) could lead to a valid cert for Google and Twitter in the hands of someone who didn't even want them.
I think a very tiny bit of blame should impute to Palo Alto Networks here. How have they built a device where it's easy to start MITMing certificates by accident? I'm all for usable crypto UI, but this seems excessive. (And should it be built with safeguards that warn you loudly when the MITM intermediate chains to a publicly-valid CA, instead of an in-house one?)
Regarding why I think it's perfectly believable that CNNIC was the easiest CA that would chain them an intermediate: everyone that runs an actual intermediate program sells (as required by the Baseline Requirements) a hardware security module, or better yet, a web interface to a cert that remains in the physical possession of the parent CA. There's an arduous audit process and key ceremony required for the intermediate CA, almost as arduous as required of the root CA. CNNIC, meanwhile, had no intermediate program, and wrote in their Certification Practices Statement that they don't intend to issue such things. So MCS was able to talk them into doing something irresponsible and handing them a CSR and no further details.
You don't accidentally do anything with an unconstrained CA key chained from the public root: that is a serious piece of data that can MITM anyone worldwide so at the very least should be under lock and key at all times! [It definitely shouldn't be plugged into any network: it should be locked in a Faraday-caged safe, on a dedicated hardware device, ideally under armed guard. You sign your operational CAs with that.]
CNNIC fundamentally broke their CPS: it has no intermediate programme, yet it intentionally misissued (at least!) one CA anyway. That is easily enough to get them pulled from everywhere, in line with current practice.
It's a pretty good demonstration of why we need something like CT, and (IMO) a public list of all intermediaries ever issued from any active CA.
But what's the alternative story? Someone knew what they were doing, wanted to MITM some users, and got a ... three-week-long intermediate certificate? (Which is far shorter than any online intermediate CA has, and those are plugged into networks, although probably also under armed guard.) And tipped their hand to Google barely a week in? Knowing that there was a serious risk to CNNIC being killed off from the roots if anyone at all noticed?
If CT has the benefit of informing bad actors that they'll be found out, then it's certainly a major one, but I find it hard to believe that anyone trying to MITM actual users wouldn't already be aware that Google is already doing this, and Chrome snitches on certs that verify but don't match hard-coded pins (e.g., for Google's own websites). This is exactly how the last MITM or two got caught.
https://groups.google.com/forum/#!topic/mozilla.dev.security...
Google https://www.chromium.org/Home/chromium-security/root-ca-poli...
Microsoft http://social.technet.microsoft.com/wiki/contents/articles/3...
Apple http://www.apple.com/certificateauthority/ca_program.html
Mozilla https://www.mozilla.org/en-US/about/governance/policies/secu...
From a cursory look Ubuntu seems to mirror Mozilla cert store.
I would myself prefer DANE being used, because it's IMHO sounder technically, but we'll possibly have the same issue with registrars doing a sloppy job than we have with CA, so not sure that it would actually be a win...
You will probably have to trust the browser vendor and the OS vendor somewhat for the foreseeable future, though. In theory, open source can help up to the hardware layer, but even that only really matters if you assume a large enough number of people are auditing every piece of code you run in practice, as well as every tool used to build it. User-auditable hardware seems unlikely any time soon, even when you assume the kind of user that reads diff patches before updating their browser install... a demographics composed of about three guys at Mozilla who are also Gentoo users.
Case in point: https://bugzilla.mozilla.org/show_bug.cgi?id=724929
IIRC, it's that event that led to a policy revision, what they did at the time (and by they I mean everyone, Mozilla included) was applying their policy of the moment.
It was one of the event that led to what happened to CCNIC...
Did you miss the discussion in the bug report? It was clear TrustWave was in violation of the policy, even at the time. If you issue a CA=YES to a 3rd party that then goes on MITMing Google, I can't imagine there exists a policy out there you are not in violation of.
And what did they do? Nothing. Instead of being the free-spirit out there, they just follow whatever Google does. Even now, they are only following Googles lead. They have the unique opportunity that their crazy compat layer affords in having their own root certificate store across all platforms, and they do nothing. It's a disgrace.
I think what google is doing there is a kind of "fact checking" ( this text on this page is really coming from this site), which means they're playing the role of a media counter power (in the sense of judiciary power, political power, and media). What's funny is that they don't need google news to play that role. Only a browser and a security policy is enough.
https://www.reddit.com/r/debian/comments/3167je/blacklisting...
How much, financially, would this action by Google affect the CNNIC CA?
The action by Google will definately impact this CA. As soon as this root certificate is no longer trusted, all Chrome users will see big warnings as soon as they visit a website that has a SSL certificate that is signed by them. I don't know the exact market share of Chrome, but I have no doubt it is large enough to make current customers of CCNIC switch to a different CA.
If the certificates were used only in a test (private?) network, how did Google find out?
Chrome also preloads HPKP information for many sites.
It's interesting to note that certificates signed by a locally installed CA (e.g. an org's MitM proxy CA) will be considered acceptable. If MCS had just made their own private root CA and deployed it to their machines there wouldn't have been an issue.
I believe this is how Microsoft Family Safety works, as far as I know.
They just, for some reason, decided that they wanted to store their cert on a Palo Alto Networks device that supported MITMing as a feature, and accidentally turned on MITM mode and plugged someone's laptop into it.
The intended use case of that feature on that device is in fact to hand it a private intermediate, not a publicly-trusted intermediate.
Playing loose and fast with a CA key and installing it on random devices like this speaks volumes about their understanding and respect of the world wide CA system.
when was the last time Google made headline of hn for its technology?
I see a "Hongkong Post Root CA" which I assume can also be used this way?
Does anyone keep a list of ones they personally like to mark as Untrusted, which doesn't break [too many] sites?