5 ms·

The fact that it's CNNIC that has issued these dangerous certificates is not exactly relevant to the problem at hand; More than one root authority has made mist

The fact that it's CNNIC that has issued these dangerous certificates is not exactly relevant to the problem at hand; More than one root authority has made mistakes in delegation, and several have made the mistake of not checking the delegation bit and allowing third-parties to request intermediate certificates. Still, it bears repeating that CNNIC, which is effectively a branch of the chinese government, has a root certificate trusted by default in all the major browsers. Unless you regularly visit chinese websites, you should remove CNNIC from your browser trust list.

geofft 12y ago
My gut agrees with you, but I found Ryan Sleevi's arguments on this thread interesting (the proposal at hand is to require, effectively, a *.cn name constraint on CNNIC): https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/pF4aVsF21ww https://groups.google.com/forum/#!topic/mozilla.dev.security... "Another reason is it encourages the trust store to be used for regional or arbitrary distinctions ('not designed to be served by that CA'). This amounts to naught more than recognizing borders on the Internet, a somewhat problematic practice, for sure. That is, for every 'constrained' CA that you can imagine that ONLY wants to issue for a .ccTLD, you can also imagine the inverse, where ONLY a given CA is allowed to issue for that .ccTLD. The reasoning behind the two are identical, but the implications of the latter - to online trust - are far more devastating. [...] "As it relates to online trust ecosystem, we can see these government CAs have either botched things quite spectacularly (India CCA) or been highly controversial (CNNIC). The arguments for CNNIC aren't 'Well, if they're only MITMing .cn users, that's OK', it's 'Well, they could MITM'. [...] "Name constraints, as presented, give tacit approval to the CAs constrained to botch things, as long as they do so only in their little fiefdoms. But when these fiefdoms easily represent millions-to-billions of Internet users, especially in emerging markets, do we really believe that their needs are being served? "That is, in essence, why I think a change like this is so dangerous. It strives to draw borders around the (secure) Internet, and to acknowledge that what you do in your own borders, to your own users, is an issue between you and them. I don't think that's a good state for anyone to be in." This doesn't directly address your proposal, that individual internet users remove CNNIC from their personal trust stores. But if we, the internet community, really believe that a branch of the Chinese government has no place in root stores, then we shouldn't allow the "weary giants of flesh and steel" to make that any different for those internet users who have the misfortune of living within or doing business within the borders of China.
- notthetup 12y ago
  I vaguely remember when talking to some ICANN people that there were talks of a system to restrict the domains which the individual root-CAs were allowed to sign for. I don't remember what happened to that.
pbhjpbhj 12y ago
I'm on FF 36.0 on Kubuntu 14.10 - I removed the certs for CNNIC and then to test went to the CNNIC website and rewrote the address as https. Website still shows the lock symbol and still shows the cert verified by the CNNIC root CA?!? Seems the removal is slightly glitchy somehow, third time worked. 2 things I notice: 1) there are a lot of default trusted suppliers, seems that this should perhaps be selected on install (trust all or trust local [geographic] or trust by selecting regions). 2) that unlike with cookies you don't get a record of how often a certificate (or CA) has been used - so I can't tell from looking at the certificate information FF holds whether I've ever used the dozen or so Turkish certs for example; this seems like useful information for users that's not being displayed. I only use Turkey as an example because I don't use Turkish websites [I barely know a handful of Turkish words] nor AFAIK any Turkish company's English language sites. Why would I need to trust geographically and linguistically distant CA's by default? If I decide to do something with a .cn site that needs a https connection it seems that I should be able to get info like "these CA - you already trust - in turn 'trust' this CA which certifies the site you are accessing". That along with any warnings the browser wants to give on malware or phishing then would feed in to a decision to accept the cert and interact "securely" with the site in question. The sites I actual need secure transactions with are probably certified by less than a dozen CA; trusting hundreds by default then seems poor security practice [to this layman].
- tptacek 12y ago
  I'm not thinking very hard about it, but that second bullet sounds like a really good idea.
  - geofft 12y ago
    Looks like Mozilla has this data in aggregate, if I'm understanding this web page right: http://telemetry.mozilla.org/#filter=nightly%2F39%2FCERT_VALIDATION_SUCCESS_BY_CA%2Fsaved_session%2FFirefox&aggregates=multiselect-all!Submissions&evoOver=Builds&locked=true&sanitize=true&renderhistogram=Table http://telemetry.mozilla.org/#filter=nightly%2F39%2FCERT_VAL... Ignore the graph and match up the table below with this C array: https://dxr.mozilla.org/mozilla-central/source/security/manager/boot/src/RootHashes.inc https://dxr.mozilla.org/mozilla-central/source/security/mana... If I'm understanding the meaning of "Bin Number" right, not all of the 0s are surprising. But some are. For instance, the AOL CA hasn't been used to sign any certs that have been seen. (I guess, in a sense, that's not really surprising...) I'd be cool if someone better at front-end than I could present the data with useful labels, and also mark each CA by whether it's in the non-Mozilla roots.
cynix 12y ago
I don't think I've ever come across a legitimate website using a certificate issued by CNNIC. It's probably okay to just distruct it altogether.
codezero 12y ago
Is there a tool/script that will: 1) list the root auths I have installed per browser 2) give me an idea of where they are relevant 3) let me deauthorize them? If not, can someone make this? :)
- Jonhoo 12y ago
  I looked around, but couldn't find one. If you're running Linux, you can do it manually yourself (blacklist all, whitelist the ones you need) in about fifteen minutes. I posted the steps for Arch Linux somewhere further down.

geofft 12y ago

My gut agrees with you, but I found Ryan Sleevi's arguments on this thread interesting (the proposal at hand is to require, effectively, a *.cn name constraint on CNNIC): https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/pF4aVsF21ww https://groups.google.com/forum/#!topic/mozilla.dev.security... "Another reason is it encourages the trust store to be used for regional or arbitrary distinctions ('not designed to be served by that CA'). This amounts to naught more than recognizing borders on the Internet, a somewhat problematic practice, for sure. That is, for every 'constrained' CA that you can imagine that ONLY wants to issue for a .ccTLD, you can also imagine the inverse, where ONLY a given CA is allowed to issue for that .ccTLD. The reasoning behind the two are identical, but the implications of the latter - to online trust - are far more devastating. [...] "As it relates to online trust ecosystem, we can see these government CAs have either botched things quite spectacularly (India CCA) or been highly controversial (CNNIC). The arguments for CNNIC aren't 'Well, if they're only MITMing .cn users, that's OK', it's 'Well, they could MITM'. [...] "Name constraints, as presented, give tacit approval to the CAs constrained to botch things, as long as they do so only in their little fiefdoms. But when these fiefdoms easily represent millions-to-billions of Internet users, especially in emerging markets, do we really believe that their needs are being served? "That is, in essence, why I think a change like this is so dangerous. It strives to draw borders around the (secure) Internet, and to acknowledge that what you do in your own borders, to your own users, is an issue between you and them. I don't think that's a good state for anyone to be in." This doesn't directly address your proposal, that individual internet users remove CNNIC from their personal trust stores. But if we, the internet community, really believe that a branch of the Chinese government has no place in root stores, then we shouldn't allow the "weary giants of flesh and steel" to make that any different for those internet users who have the misfortune of living within or doing business within the borders of China.

notthetup 12y ago
I vaguely remember when talking to some ICANN people that there were talks of a system to restrict the domains which the individual root-CAs were allowed to sign for. I don't remember what happened to that.

pbhjpbhj 12y ago

I'm on FF 36.0 on Kubuntu 14.10 - I removed the certs for CNNIC and then to test went to the CNNIC website and rewrote the address as https. Website still shows the lock symbol and still shows the cert verified by the CNNIC root CA?!? Seems the removal is slightly glitchy somehow, third time worked. 2 things I notice: 1) there are a lot of default trusted suppliers, seems that this should perhaps be selected on install (trust all or trust local [geographic] or trust by selecting regions). 2) that unlike with cookies you don't get a record of how often a certificate (or CA) has been used - so I can't tell from looking at the certificate information FF holds whether I've ever used the dozen or so Turkish certs for example; this seems like useful information for users that's not being displayed. I only use Turkey as an example because I don't use Turkish websites [I barely know a handful of Turkish words] nor AFAIK any Turkish company's English language sites. Why would I need to trust geographically and linguistically distant CA's by default? If I decide to do something with a .cn site that needs a https connection it seems that I should be able to get info like "these CA - you already trust - in turn 'trust' this CA which certifies the site you are accessing". That along with any warnings the browser wants to give on malware or phishing then would feed in to a decision to accept the cert and interact "securely" with the site in question. The sites I actual need secure transactions with are probably certified by less than a dozen CA; trusting hundreds by default then seems poor security practice [to this layman].

tptacek 12y ago
I'm not thinking very hard about it, but that second bullet sounds like a really good idea.
- geofft 12y ago
  Looks like Mozilla has this data in aggregate, if I'm understanding this web page right: http://telemetry.mozilla.org/#filter=nightly%2F39%2FCERT_VALIDATION_SUCCESS_BY_CA%2Fsaved_session%2FFirefox&aggregates=multiselect-all!Submissions&evoOver=Builds&locked=true&sanitize=true&renderhistogram=Table http://telemetry.mozilla.org/#filter=nightly%2F39%2FCERT_VAL... Ignore the graph and match up the table below with this C array: https://dxr.mozilla.org/mozilla-central/source/security/manager/boot/src/RootHashes.inc https://dxr.mozilla.org/mozilla-central/source/security/mana... If I'm understanding the meaning of "Bin Number" right, not all of the 0s are surprising. But some are. For instance, the AOL CA hasn't been used to sign any certs that have been seen. (I guess, in a sense, that's not really surprising...) I'd be cool if someone better at front-end than I could present the data with useful labels, and also mark each CA by whether it's in the non-Mozilla roots.

cynix 12y ago

I don't think I've ever come across a legitimate website using a certificate issued by CNNIC. It's probably okay to just distruct it altogether.

codezero 12y ago

Is there a tool/script that will: 1) list the root auths I have installed per browser 2) give me an idea of where they are relevant 3) let me deauthorize them? If not, can someone make this? :)

Jonhoo 12y ago
I looked around, but couldn't find one. If you're running Linux, you can do it manually yourself (blacklist all, whitelist the ones you need) in about fifteen minutes. I posted the steps for Arch Linux somewhere further down.