Google pulling China CNNIC CA from its products(googleonlinesecurity.blogspot.com)
googleonlinesecurity.blogspot.com
Google pulling China CNNIC CA from its products
http://googleonlinesecurity.blogspot.com/2015/03/maintaining-digital-certificate-security.html?m=1
165 comments
> If you don't the whole system is worthless.
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.
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.
>it should be replaced with something more like bitcoin.
What does that even mean?
What does that even mean?
He was probably talking about the centralised model used with CAs, and trying to start a discussion about an alternative to the CA model, probably some way of decentralised control, hence the bitcoin reference.
Convergence [1] comes to mind.
[1] http://convergence.io/
[1] http://convergence.io/
I would be in favor of decentralised as well; nobody should have to pay money to some bunch of trolls just to use encryption; this is a friction point for a lot of newcomers to web development. In fact, making HTTPS free to use would probably be the best thing that could ever be done for cybersecurity for mankind. Make it zero-friction over HTTP, somehow.
Perhaps Google might want to sponsor this? :)
Perhaps Google might want to sponsor this? :)
> In fact, making HTTPS free to use would probably be the best thing that could ever be done for cybersecurity for mankind
I guess we'll eventually get there, but unless we get decentralised I don't see how it could be done.
I guess we'll eventually get there, but unless we get decentralised I don't see how it could be done.
Let's encrypt works on the assumption that there is no reason why https certificate cannot be easy (not as cumbersome?) to use AND free of cost. They hope to start availability in the middle of this year. Free of cost is possible. We just need to make it easy, reliable, and repeatable for domain name owners to prove their ownership.
https://letsencrypt.org/
https://letsencrypt.org/
For the time being, use CloudFlare. They have SSL enabled even in the free plan.
CloudFlare is funded by the department of homeland security: http://thenextweb.com/insider/2011/06/07/cloudflare-a-websit...
Why is that a proper reply/
Basically it means that I think that hierarchical trust doesn't work for me. Instead of bank buying certificate from some authority I'm supposed to trust I'd rather infer that this certificate is associated with this domain because it's written in some form of blockchain, unalterable and verified by multiple parties.
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.
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 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?
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.
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.
because web-of-trust-models worked so great for PGP/GPG. In theory that's great, but how can I confirm that the cert in the chain is indeed for google.com. Because it's trusted by chrome which I downloaded from google.com (or at least a machine pretending to be google.com) or because my computer-illiterate friends trust it? Or because my OS trusts that cert?
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.
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.
There's lots of newer research on trust-based systems that could be applicable here, e.g. a game-theoretic approach where entities are gauged based on ratings over repeated transactions. Think iterated prisoner's dilemma crossed with PageRank, which effectively wards against many types of collusion including simple sybil attacks. Most of it hasn't been validated in the real world on any scale, but I believe it is possible to do quite a bit better than we have seen - the only web-of-trust stuff I've seen in practice is ancient compared to the state of research.
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".
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".
I agree, the bootstrapping trust is a hard issue, and I don't think either that a distributed system will magically fix things. What would happen is we'd just change one set of problems for another one, but IMHO it'd be a better system overall. In this case, making things more visible is a better thing. That's an interesting point about the way a distributed model would evolve. My question is: does it matter? If we could more easily spot a bad actor, wouldn't it make everyone behave better?
Please check my response to sibling commenter.
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.
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.
Bring back the key exchange parties of old :D
Thanks for clarifying.
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.
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.
From what I understand, and as I said I don't know much, the purpose of not self-signed certs is to provide trustworthy information about identity of entity that controls the domain.
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.
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.
Probably something like this: https://github.com/okTurtles/dnschain
it doesn't mean anything; just another parrot
Replacing with a blockchain is a horrible idea. If the certificate gets compromised, how do you handle revoking the old certificate? How do you handle someone having a domain name like paypa1.com? There are a lot of cases where having a human in the loop is a good thing for overall security. Now, this isn't to say that the current system isn't broken as hell, but a bitcoin type solution is definitely not the way to do it.
[Namecoin](https://namecoin.info/) is exactly that - in particular it's .bit domain is an attempt to be a blockchain-based decentralized DNS registrar. I'm not sure of the exact state of Namecoin with respect to DANES or other domain<->certificate binding protocols, but it looks like a pretty good start on the job.
Unfortunately this won't make a big splash, unless MS takes action in solidarity with Google. MSIE and its variants are still the vast majority of the desktop browser market in China, by a huge margin.
For posterity:
http://i.imgur.com/8d7Uama.png
http://i.imgur.com/8d7Uama.png
Hey mate, your "2011 breach incident" anchor points to nothing in the page. Am I missing something?
It seems to be [here](http://en.wikipedia.org/wiki/Comodo_Group#Controversies) now.
[edit]
Let's try this again: https://www.schneier.com/blog/archives/2011/03/comodo_group_...
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 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...
It's a short update, but I can make it shorter:
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.
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.
Good riddance.
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.
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.
> 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.
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.
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.
Yes, "name constraints" is what I was suggesting. (I vaguely remembered that there was something in the relevant standards that allow such constraints, but I couldn't remember the name and wasn't sure that it was actually in the standards. So I just tried to explain the idea.)
https://tools.ietf.org/html/rfc5280#section-4.2.1.10
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.
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.
There are tons of edge cases here.
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.
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 perfect case where tech giants can increase "cost of doing business" for NSA. NSA is having it too easyfucking over citizens. Now let them try fucking over businesses and still get away with it.
I think that this is a great reason to have zero-tolerance policy to CAs fuckups.
I think that this is a great reason to have zero-tolerance policy to CAs fuckups.
My thoughts exactly. The world is not a chess board. The rest of the pieces don't just stay where they are and watch passively while you make a move. It may take a while for the full effects to be felt, but sooner or later the board as a whole will find a new equilibrium.
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.
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.
We bust the certs all the way to the CA. If it's been acquired through "extralegal" methods (an interesting word to not say "illegal", even though we all know it is), no matter who did it, security is compromised.
> As soon as you fuck up, you're out.
That would create an even bigger incentive than today to cover any misuse up. Not sure that's what we want.
That would create an even bigger incentive than today to cover any misuse up. Not sure that's what we want.
Heh, let the arms race begin!
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.
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.
I was thinking of relaxing Mozilla's root inclusion requirements (I suggest to the same as Microsoft's) for government CAs in exchange for name constraints.
Do you honestly believe that government organizations don't already have their own people in these CAs that are issuing certificates whenever they want?
> As soon as you fuck up, you're out.
You would have no CA's then. I love when people criticize others without offering a anything in return.
You would have no CA's then. I love when people criticize others without offering a anything in return.
No, GP actually has a point. Once you do things like this, you're out. Once you're out, you become a nobody.
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.
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.
Not a good comparison technically, but everyone makes mistakes. And the 2010 event was promulgated by "untrustworthy" employees. The system is risky, and change will have to come sooner or later.
http://www.reuters.com/article/2012/02/02/us-hacking-verisig...
http://www.reuters.com/article/2012/02/02/us-hacking-verisig...
CAs are supposed to be in the business of trust. We are supposed to hold them to the highest standard of machine trust. If they screw up and fix the error in a matter of hours or days... alright. But CAs who charge money for making certificates need to earn our dollars.
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.
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.
Nah, we'd still have plenty of CAs at any given time. After all, it's highly unlikely that all of them will fuck up at the same time. If you buy from a reputable CA, there's at least 90% chance that you won't have any issues during the life of your certificate (1-2 years).
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!"
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!"
Or just create a TLS extension that allow all of the chains to be served as part of the TLS Certificate message.
There's even an SSL extension for the client to mention its list of trusted root CAs in its side of the handshake. It's very rarely used on desktop / on the public Internet because people tend to trust more CAs than would fit in a TCP packet, but it's apparently useful enough in embedded scenarios to standardize.
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.
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.
Unfortunately, that's not valid per the RFCs (from rfc 5246, TLS 1.2):
"certificate_list
"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."
Just edited my comment.
> You would have no CA's then.
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.
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.
I think the proper number of CAs is a lot closer to zero than it is to the current hundreds.
CNNIC has responded: http://www1.cnnic.cn/AU/MediaC/Announcement/201504/t20150402...
> 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.
> 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.
> The decision that Google has made is unacceptable and unintelligible to CNNIC
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.
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.
> That's now this works.
Correcting self: that's /not how/ this works.
Correcting self: that's /not how/ this works.
The decision that Google has made is unacceptable and unintelligible to CNNIC,
Standard language of the authoritarian mindset, everywhere.
Standard language of the authoritarian mindset, everywhere.
Glad to see this happening - I removed CNNIC from my machines back in Feb - https://github.com/sammcj/delete-unknown-root-ca
Is there a readily accessible list of the CAs you're deleting? Ah, it's in the shell script itself, and there are just four of them. And this looks to be specific to Mac OS X only -- /System/Library/Keychains is not a frequently encountered path on, say, Windows, Linux, or BSD (non-Mac) boxen.
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.
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.
As the readme says: 'Also removes any user trust settings for each certificate'.
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.
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.
If you want remove all China CAs, it may be helpful.
https://github.com/chengr28/RevokeChinaCerts
Great link - thanks!
[deleted]
This is what I hoped would happen when we learned about the malicious intermediate: https://news.ycombinator.com/item?id=9254899
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.
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.
Can't think of a better response than this.
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.
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.
> Hopefully CNNIC deploys CT
What are the odds they'll do this? I'd bet extremely high.
What are the odds they'll do this? I'd bet extremely high.
CNNIC is a joke, don't put any hope to them please.
No, it is not a joke. Seriously, it was one of the major manufacturers of malware (CNNIC中文上网, with rootkit included) in China.
Yes. But don't put hope to CNNIC as don't put hope to China government. They don't need google accept them because there are a lot companies provide browsers in China.
Please elaborate.
[deleted]
From the original part: "MCS Holdings on the basis that MCS would only issue certificates for domains that they had registered"
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?
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?
The missing detail is that this "delegation" to an intentionally MITMing CA should never have been made in the first place. Using such a certificate in an HSM does not make that acceptable, and I don't have the impression that it would have been acceptable even in an HSM; I think that portion of the article was simply relaying the information CNNIC provided (in which they're trying to shift the blame onto MCS Holdings for further mishandling of an intermediate CA that should never have been issued in the first place).
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.
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.
There was no intention to MITM here. MCS's goal was to become a certificate authority, and it's common practice for a new CA to get their CA cert signed by an existing one. Let's Encrypt is planning on doing exactly this, for instance.
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...
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...
> MCS unintentionally placed the cert on a device that happens to do real-time SSL MITM
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.
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.
> 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.
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.
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.
A CA hitting the "generate CSR" button and not knowing what it does should not be a CA, full stop. 100% of the job of a CA is understanding private keys, public keys, CSRs, and the security policies surrounding them.
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.
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.
I think it's possible for the CA to delegate the authority to a specific subset of domains. But in this case MCS holdings apparently was given a certificate allowing them control over everything.
I'm not 100% sure, but fairly certain the way that x.509 works, there is a boolean field for whether or not the certificate is an authority, with no control over what they are an authority for. I believe this field is called basic constraints.
There is something called "name constraints" in X.509 that can be used to control which domain names, email addresses, etc. a sub-CA certificate can issue certificates for. See [1]. CAs are using them more and more frequently, especially after Mozilla added items #9 and #10 [2] to its inclusion policy a couple years ago.
[1] http://tools.ietf.org/html/rfc5280#section-4.2.1.10
[2] https://www.mozilla.org/en-US/about/governance/policies/secu...
[1] http://tools.ietf.org/html/rfc5280#section-4.2.1.10
[2] https://www.mozilla.org/en-US/about/governance/policies/secu...
Apparently name constraints don't constrain the CN field though, and that's what browsers validate domain names against.
In Mozilla's implementation, name constraints are applied to the CN field. I believe Chrome is the same way. Also, browsers "validate domain names" against the CN attribute and the dNSName entries in the subjectAltName extension.
Source: I wrote all that code in Mozilla's implementation.
Source: I wrote all that code in Mozilla's implementation.
Are there any CAs issuing these? How do I get a CA certificate with a name constraint for my domain?
Have you reasons to believe the existing x509 certificates handling code handles properly an extension that is seldom used, and will do it in all cases?
Validation of x509 certificates is ridiculously complex, and CA rightfully only use the widely interoperable subset of extensions...
Validation of x509 certificates is ridiculously complex, and CA rightfully only use the widely interoperable subset of extensions...
Some implementations--most unfortunately, Apple's--do not implement name constraints.
Speaking from personal experience, writing code to correctly validate x509 certificates isn't as hard as it looks.
Speaking from personal experience, writing code to correctly validate x509 certificates isn't as hard as it looks.
Then you're likely in the top 10 experts of the field ;)
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.
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.
I wonder about the downvotes, with the long documented history of software failing to properly validate certificate chains (or worse, trees).
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...
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...
There are several (most famous is Verizon), but they tend to target larger companies.
It's just an organizational decision. CNNIC is super trustworthy to a lot of people. It's so many people, in fact, that they can't possibly verify all of the sites these people want to visit. So instead of burdening CNNIC with verifying the identity of every single site that wants a cert that their users will trust, CNNIC will just verify some other CAs as being trustworthy enough to do the job.
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.
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.
> CNNIC is super trustworthy to a lot of people
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
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
> No, CNNIC is not even trustworthy among Chinese Internet users.
CNNIC is not trustworthy especially among Chinese Internet users.
CNNIC is not trustworthy especially among Chinese Internet users.
absolutely! In general I trust pure commercial organisations more than govt. and non-profit orgs.
> CNNIC is not even trustworthy 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.
1. https://en.wikipedia.org/wiki/Yahoo!_Assistant
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.
1. https://en.wikipedia.org/wiki/Yahoo!_Assistant
> Oh? Then why did Firefox, Google, Microsoft, Apple, etc. trust their root certificate?
Mozilla no longer trust CNNIC.
https://blog.mozilla.org/security/2015/04/02/distrusting-new...
Mozilla no longer trust CNNIC.
https://blog.mozilla.org/security/2015/04/02/distrusting-new...
Yes, hence my using the past tense. I do not see how "CNNIC is [not trustworthy]" is compatible with "Firefox, Google, Apple, and Microsoft trusted their certificates until MCS Holding screwed up some corporate network's https-interception implementation".
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?
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?
TFA is about the fact that Google no longer does trust CNNIC. And Mozilla no longer does, for the same reason.
MCS has a very sloppy response: http://www.mcsholding.com/MCSResponse.aspx
These two PDFs got sent by CNNIC to mozilla.dev.security.policy by way of explanation:
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.
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.
No, I find that pretty damn hard to believe. Especially considering where it's coming from.
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.
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.
Yeah, to be clear, I think this was inexcusable, even if it wasn't outright malice, and that expulsion is the obvious right answer.
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.
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.
I think the concern here is not that MCS made a mistake, but rather, CNNIC said they wouldn't do something and then knowingly did so. Whether they had good intentions or not is irrelevant. They made a public promise they wouldn't issue intermediate CAs, did so for money and the result of that must be at least temporary revocation. Otherwise the whole notion of trust collapses.
Sloppy on multiple levels.
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.
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 think the main problem with giving it to someone else to sanity check is that if your own English isn't good, you'll have a hard time gauging someone else's English speaking skills.
I wouldn't be surprised if they did give it to someone who they thought spoke English well.
I wouldn't be surprised if they did give it to someone who they thought spoke English well.
I do like the lines "the best of bread solutions" and "the sack of unintentional action" though.
This is an Egyptian company. I had many expat friends when I lived there I will tell you beyond the most elite multinational corps no one sees the point.
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.
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.
Wonder if Mozilla will follow suit:
https://bugzilla.mozilla.org/show_bug.cgi?id=542689
The Mozilla root program currently has a similar plan proposed, with a final decision pending in the next day or so.
https://groups.google.com/forum/#!topic/mozilla.dev.security...
https://groups.google.com/forum/#!topic/mozilla.dev.security...
Why should we trust browser authors with their CA list (google, firefox, etc...)? PKI should be rethought because in its current form we are relying heavily on their trust. Sadly to the average user have no clue what's going on.
Read the root certificate inclusion policy of your vendors. In the end it comes down to how much you trust the vendor to implement the policy faithfully and whether you agree with the policy itself.
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.
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.
Lovely words, of course in the case of Mozilla we already know its wholly worthless. Disregard whatever they write to the contrary.
Case in point: https://bugzilla.mozilla.org/show_bug.cgi?id=724929
Case in point: https://bugzilla.mozilla.org/show_bug.cgi?id=724929
Why do you single out Mozilla? Trustwave is still trusted by Microsoft and Google too...
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...
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...
I didn't single them out, Mozilla singled themselves out of the others. They insist on being the only free browser out there, and when push comes to shove, they collapse.
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.
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 understand. But the fact that I need to trust the vendor and the CAs is a broken concept.
At some point, as an individual user, you have to trust someone: the browser's vendor, the OS vendor, the hardware vendor, the component's vendor, the factory/distribution chain. For now, trusting the browser seems relatively inevitable. Trusting CAs might not be the only alternative for long, however: https://namecoin.info/ (as one of a few possible but not quite ready for prime time solutions).
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.
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.
Yet it works with way over five nines confidence. Despite all its faults, the system works decently.
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...
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...
DANE has its own issues though: by itself, even if you're using DNSSEC with it (as you ought to be), you're essentially shifting trust from CAs to registry operators, your DNS service provider, and whoever operates the root zone.
We need someway to authenticate websites. The only viable alternative I know is DANE with DNSSEC. As long as DNSSEC is not widely deployed - and actually authenticated on the client - what alternative is there?
This is worse than not having an alternative because it gives a sense of security to people without knowing whom they are trusting.
I just had an epiphany , when thinking about what role are those big companies playing now in our democracy, in the most general sense.
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.
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.
Google is the single most important factor in modern democracy as information is power. Hence "Don't be evil."
Debian, Ubuntu, and derived systems can flag CNNIC )if they've installed the 'ca-certificates' package) as untrusted themselves using /etc/ca-certificate.conf:
https://www.reddit.com/r/debian/comments/3167je/blacklisting...
https://www.reddit.com/r/debian/comments/3167je/blacklisting...
We really need to clean up the CAs. Hopefully once the lets encrypt guys gets to be operational we can nuke the rest, in a similar way to how Chrome is sunsetting the old encryption standards.
This is just an alarming sign that the entire SSL business is broken. It was exploited so many times by western agencies and also by criminals that it should be clear to everybody that this workflow is broken. This action from Google is an example of double standards. There are CAs from three letter friends in some of the tools we are using today so they can silently mitm attack your SSL traffic. I don't see Google rushing to fix the underlying problem and just trying to mess with China.
Re: 3 letter friends CAs, I believe it. Sort of have to do that, given their operating goal of being able to read everything at will. Its low-hanging fruit, and the only real reason to continue with such a centralized authority-based scheme is to support that type of thing.
Well, I would agree with you if this opportunity could not be exploited by malicious organizations.
This is the right move. It had to escalate compared to ANSSI case, because back then the claim was "this is the last time".
Yea, they claimed that they were going to take years to comply with the BRs. They ended up limiting it to French TLDs. It seems that they are finally phasing out this CA now.
I've no idea about the business of Certificate Authorities. Are they non-profits (like other Internet infrastructure organisations, data centers etc) or corporations?
How much, financially, would this action by Google affect the CNNIC CA?
How much, financially, would this action by Google affect the CNNIC CA?
They are corporations. Their most important asset is trust, which they need to keep by not signing certificates that can be used for malicious purposes.
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.
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.
What does this mean:
"...nor do we believe the misissued certificates were used outside the limited scope of MCS Holdings’ test network,..."
If the certificates were used only in a test (private?) network, how did Google find out?
If the certificates were used only in a test (private?) network, how did Google find out?
I believe Chrome will report back when it finds an improperly issued certificate.
https://scotthelme.co.uk/hpkp-http-public-key-pinning/
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.
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.
They weren't even trying to do that, is the saddest part. They were trying to be a real CA, but they weren't trying to MITM. (It's common practice for new / young CAs to chain their CA cert off a more established CA.)
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.
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.
"accidentally".
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.
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.
> 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.
I believe this is how Microsoft Family Safety works, as far as I know.
This is how all corporate SSL inspection works.
[deleted]
Does this mean Chrome on iOS will reject these certs? It's a bit unclear. I know they have to use the Safari rendering engine but I'm curious if there are any other internals at play here.
I believe iOS lets you specify your own validation callback. (For instance, I think best practice is for a random app on iOS, that only connects to its own servers for an API, to manually pin the public key and a backup public key for the server or at best a handful of CAs, instead of trusting the entire set of root CAs.) I don't know how extensively Chrome is using that feature.
Well done! I hope Google would do the same when related to NSA and other 3 letters agencies.
when was the last time Google made headline of hn for its technology?
when was the last time Google made headline of hn for its technology?
Does anyone have a list of all typical root CAs and where they are issued from? Are there any other CAs that can be used in rogue ways?
I see a "Hongkong Post Root CA" which I assume can also be used this way?
I see a "Hongkong Post Root CA" which I assume can also be used this way?
Thanks for the reminder to recheck my certs. I manually wiped CNNIC (among others) when the news first broke, and with today's Firefox update, I'll check again.
You can't just "wipe" a Root CA on Windows - you have to explicitly untrust it.
Open certmgr.msc and put the certificate into the "Untrusted Certificates" store.
I don't remember deleting it, but also can't find one that seems to be from CNNIC.
Does anyone keep a list of ones they personally like to mark as Untrusted, which doesn't break [too many] sites?
Does anyone keep a list of ones they personally like to mark as Untrusted, which doesn't break [too many] sites?
Look for "China Internet Network Information Center EV Certificates Root" and "China Internet
Network Information
Center (CNNIC)" (thumbprints 4F99AA93FB2BD13726A1994ACE7FF005F2935D1E and 8baf4c9b1df02a92f7da128eb91bacf498604b6f)
Windows downloads root certs just in time.
China versus Google. Let me get the popcorn.
what about wosign?
I've distrusted the CNNIC roots in my browsers but left WoSign alone for now. Is there any indication that they should also be distrusted?
When there is a indication, it would be too late.
WoSign is actually a separate commercial CA though as far as I know.
not affected as it doesn't use CNNIC as root
Ex: http://en.wikipedia.org/wiki/Comodo_Group#2011_breach_incide... Nothing happened after this breach, which was a shame.