8 ms·

Google warns of unauthorized TLS certificates trusted by almost all OSes

205 points by shawndumas 12y ago

blencdr 12y ago
It's a good point for Firefox to embed is own certificates. I wonder if there is such unauthorized certs in Firefox manager.
chaitanya 12y ago
It is interesting that when the CNNIC root certificate was added to Firefox, this is exactly what many people had warned against: https://bugzilla.mozilla.org/show_bug.cgi?id=476766 https://bugzilla.mozilla.org/show_bug.cgi?id=476766
- ttflee 12y ago
  IMHO, had Firefox dared remove CNNIC root cert, Mozilla would already been ousted with their business in China, like Google.
fensipens 12y ago
Goodin can't help but say borderline moronic things every once in a while: Defenders of current system for acquiring and and revoking TLS certificates have recent chafed in response to statements from this author that it's hopelessly broken. Besides remembering that almost all of these critics have a strong financial interest in the way the system works now "chafed" because of this: https://twitter.com/ivanristic/status/578536108662861824 https://twitter.com/ivanristic/status/578536108662861824 So Ristic working for ssllabs automatically disqualifies him from asking the perfectly valid question "What is a better approach, in your opinion?".. You still like your Goodin, tptacek? ;)
blueskin_ 12y ago
The CA system is fundamentally broken. Centralised authorities are bad.
willvarfar 12y ago
Why can the CN registrar sign .com certs? Why aren't national authorities limited to their country's TLD? I'd imagine they'd want this, and the public would want this. Its so obvious, what am I missing?
- danyork 12y ago
  Any CA can generate a cert for any domain. This is one of the problems with the current CA system.
acd 12y ago
Central certificate authorities were all web users put their trust against money compensation to the CA are a broken security model! Especially in the new internet security era were we have government hackers with almost unlimited budgets. Governments will hack into CAs and issue fake certificates to popular domains that they want to Man in the middle attack and to that we have no protection. I think the solution is a voting mechanism or digital ID. So that the engineer working at Google can sign the certificate with a Corporate Google ID. Central CAs is almost as broken security as credit cards with the card number readable in cleartext on the front of the card.
gislifb 12y ago
Has anyone gone throught the list of root certificates that are trusted in the browsers/OSes and done some homework on them? Would be interesting to see what's behind those authorities and also which certificates they have issued. I see that in the OS X keychain I have 213 "system roots" that are trusted, I wonder how many of them I really need...
PythonicAlpha 12y ago
Action is really needed. A system that can be breached just by any CA company that is more interested in money than in security (also at least one big CAs has a bad history concerning security) is plainly broken. There should at least be a kind of overseer that has the ability to intervene when bad behavior is reported. In the current situation, it is impossible to trust this "system of trust". It just sounds similar as I shall give the keys to my house to the thieves guild to prevent burglaries.
- geofft 12y ago
  Certificate Transparency is a solution. It's not my favorite solution, but it's far and away my favorite solution that stands a chance of working. http://www.certificate-transparency.org/ http://www.certificate-transparency.org/ This particular bad behavior, like entirely too many other breaches, was (probably) noticed because Google's own browser saw illegitimate but valid Google certificates, and alerted Google through its own channels. CT extends that to any other site that wants to participate. CT also requires that CAs disclose every certificate that's signed, including those signed by intermediates that they give to third parties. This doesn't make legitimate use of intermediates much more onerous, but it makes MITMing-proxy use extremely logistically complicated, even if you felt like telling the whole world you were MITMing certificates.
  - itistoday2 12y ago
    > Certificate Transparency is a solution CT would not have prevented these attacks. Google would be exactly where they are right now: knowing who issued cert, and that's it. Short form: https://github.com/okTurtles/dnschain/blob/master/docs/Comparison.md https://github.com/okTurtles/dnschain/blob/master/docs/Compa... Long form: https://blog.okturtles.com/2014/09/the-trouble-with-certificate-transparency/ https://blog.okturtles.com/2014/09/the-trouble-with-certific... (EDIT: How about an honest discussion instead of a downvote? If you disagree, you are welcome to explain why.)
    - geofft 12y ago
      Given the operational difficulty of implementing a transparently-MITMing proxy in a Certificate Transparency regime, I'm not sure you can say with certainty that it wouldn't have prevented this attack. Every time you want to MITM a new site, you need to contact some number of auditors before you can complete the connection. That sounds difficult to implement reliably and quickly enough for a MITM to work. (Not to mention that most off-the-shelf MITM proxies will intentionally not implement this, since the use case for legitimate MITM proxying involves using site-specific CAs, not globally-valid CAs, so you'd have to deploy custom code to go talk to the auditors. And I somehow have doubts that a robust, black-hat MITM proxy solution will emerge, given that it probably will have only a handful of users at any given time.) In any case, it is certainly not a perfect solution. But it is a solution. I've read that okTurtles blog post before. Insofar as it points out that CT has limitations, it's generally right. But the okTurtles scheme is much worse: if a certificate gets compromised, the only recourse is to pick a new website name. I think it's likely that there is no perfect solution here. CT makes no claims for perfection, but it's a pretty good imperfect solution, and I think we need that more than we need a nonexistent perfect solution. BTW: "Resist commenting about being downvoted. It never does any good, and it makes boring reading."
geofft 12y ago
http://googleonlinesecurity.blogspot.com/2015/03/maintaining-digital-certificate-security.html http://googleonlinesecurity.blogspot.com/2015/03/maintaining... is a better URL. (For potential future reference, the current URL is http://arstechnica.com/security/2015/03/google-warns-of-unauthorized-tls-certificates-trusted-by-almost-all-oses/ http://arstechnica.com/security/2015/03/google-warns-of-unau... )
- falcolas 12y ago
  I disagree, in this case the direct link is not a better URL. The Ars Technica article (as many issues as I have with them) correlates not only the Google alert, but also followup conversations on Twitter and from Mozilla. This kind of correlation (and analysis) is the very definition of adding value added. It also clearly links to the Google blog, so it's hard to accuse them of trying to co-opt Google's content as their own.
- ikeboy 12y ago
  Ars named the countries that the companies were from. I was half-wondering that when I saw the Google link, I'm happy I saw the ars one after.
GauntletWizard 12y ago
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.
deleted 12y ago
[deleted]
_RPM 12y ago
I've always had the suspicion that my pc had some sketchy certs installed.. what do ya expect from buying a pc with an OS installed from an electronics retailer..right?
- Buge 12y ago
  I'm pretty sure it's a default install in Windows, so the retailer doesn't really make a difference.
  - ptaipale 12y ago
    The retailer doesn't. The vendor (who chooses what to pre-install) does.
_RPM 12y ago
I've always had the suspicion that might my pc had some sketchy certs installed.. what do ya expect from buying a pc with an OS installed from an electronics retailer..right?
pilif 12y ago
Just revoking the intermediates is not enough. This tells the main culprits that it's ok to issue intermediates to do whatever and then deny responsibility as it gets detected. The only possible course of action is to hold the root responsible and to remove them from the trust store. The CA system is fragile enough as it is and only the prospects of immediately going out of business can be any deterrent for CAs not to start doing shady stuff. Yes. Revoking the root is annoying for customers of that root, but I'm sure other CAs will gladly offer a free or really cheap replacement program. And if the affected root is REALLY big, then just pre-announce the revocation for a year or two. Just like what Google is doing with the sha1 certs.
- methou 12y ago
  I have marked CNNIC root cert untrusted on all of systems I can control. It bothers me sometimes when some providers with "good" reputation uses them, like azure china. I had to manually add the server certificate to trusted list, just to manage my vms. Otherwise, I barely notice the issue. It looks that even CNNIC certs themselves weren't widely deployed, correct me if I'm wrong, most of Chinese sites who wants to employ TLS doesn't do it right, for example, 12306 has its own root and some sites I use daily has a self-signed CA with random input in all of the fields.
  - higherpurpose 12y ago
    If you think the company that has agreed to collaborate with a Chinese company to make a different version of Skype (Tom-Skype), for the sole purpose of letting the Chinese government spy on Chinese citizens' communications in real-time, can be "trusted" to not have backdoored cloud services in China, then I have a bridge to sell you. Microsoft has proven again and again that it's willing to make any concessions to the Chinese government if there's the slightest chance of them making an extra percent market share in China. We saw that when Google was hacked by the Chinese government, too. Microsoft was more than happy to agree to all the censorship policies Google didn't, because it meant that maybe possibly that would earn them some market share in China, after Google would be gone - it didn't anyway. Baidu took all that difference Google lost.
Jonhoo 12y ago
FWIW, here's what I just did on my (Arch) Linux machine: $ for f in /etc/ssl/certs/*.pem; do sudo ln -sfn "$f" /etc/ca-certificates/trust-source/blacklist/; done $ sudo update-ca-trust This will block all currently installed CAs (as well as double-block some, but that doesn't really matter). You then need to add them back in. Restart your browser, and go to websites you access frequently (change them to https:// https:// if necessary). Click the (broken) padlock and read off what CA they used; remove the corresponding .pem file from the blacklist directory. Some might be signed by intermediate certs and thus hard to find, but SSL Hopper has a great chain inspection tool at https://www.sslshopper.com/ssl-checker.html https://www.sslshopper.com/ssl-checker.html you can use to identify the topmost CA cert you need to whitelist. After you're done, run "sudo update-ca-trust" again, and restart your browser. All normal sites should work, and you've gotten rid of ~160 root certs. If it's of interest to anyone, here are the ones I whitelisted to get all sites I bothered to try up an running: $ sudo rm DigiCert_* GeoTrust_* Go_Daddy_* GlobalSign_* VeriSign_* StartCom_Certification_Authority* Comodo_* AddTrust_* Thawte_* thawte_Primary_Root_CA* Baltimore_CyberTrust_Root.pem UTN_USERFirst_Hardware_Root_CA.pem Visa_eCommerce_Root.pem $ ls /etc/ssl/certs/*.pem | wc -l 206 $ ls /etc/ca-certificates/trust-source/blacklist/ 163 EDIT: Note that this is not a perfect solution; the CAs you've whitelisted could still go bad, and you'll need to blacklist any new CA certs that are added with subsequent ca-certificates updates. But it's a start.
- kpcyrd 12y ago
  Be careful, this has no effect if you're using firefox/iceweasel. They bring their own set of trusted CAs and ignore all changes on the OS trust store.
- pyre 12y ago
  You've said the start by blacklisting all SSL, then to inspect the SSL chain using SSL Shopper, but the link to SSL Shopper is using https. So (at least the first time), you need to inspect yet another SSL cert before you can inspect the other SSL cert you were looking at. :P (FYI, looks like SSL Shopper uses GoDaddy for SSL)
methou 12y ago
The day has come.
nly 12y ago
If they implemented and enabled DANE in Chromium then we could detect and render harmless this miss-issuance for our domains via PKIX-TA Certificate Authority Constraints instead of playing Whac-A-Mole
danyork 12y ago
So what do we do to fix the broken CA system? Particularly in a case where a bogus certificate is issued by an intermediate CA that rolls up to a root CA that is included in all the major browsers. It seems to me that we have several building blocks available and it may be a combination we need: 1. CERTIFICATE PINNING (HPKP) - example: http://tools.ietf.org/html/draft-ietf-websec-key-pinning-21 http://tools.ietf.org/html/draft-ietf-websec-key-pinning-21 - if a browser had previously pinned the certs of affected sites then it would have known that it was going to bogus sites and could have displayed a warning or prevented the user from going to those sites. The challenge with pinning is that somehow you have to learn what to pin before you visit a site, either by having the pinset or certs pre-loaded into the app/browser or simply by doing Trust On First Use (TOFU). Additionally, if the first use is to the site controlled by an attacker, the cert that gets pinned in the browser could in fact be the attacker's cert, which could make recovery difficult. Which brings us to... 2. DANE/DNSSEC - http://www.internetsociety.org/deploy360/resources/dane/ http://www.internetsociety.org/deploy360/resources/dane/ - with DANE (RFC 6698) you put a fingerprint (or an entire cert) into a TLSA record in DNS and then sign that with DNSSEC. A browser or app that supported DANE could deal with the TOFU issue by doing a DANE check to verify the cert that it is receiving from the web server. This would then effectively bootstrap the cert pinning process by providing a way to test the validity of the cert. Because the DANE TLSA records are entered by the owner/operator of the domain and then through DS records are tied into a validated chain-of-trust up to the root of DNS, it would be difficult for an attacker to subvert this with his/her malicious TLSA records. But we have a third layer to help... 3. CERTIFICATE TRANSPARENCY (CT) - http://www.certificate-transparency.org/ http://www.certificate-transparency.org/ - CT provides a way to log all the issued certs and have browsers/apps check those logs through an auditor. When the browser gets the TLS cert, it also gets a signed cert timestamp (SCT) and can use that through an auditor component to check if the cert is valid. The challenge is that right now only some CAs log issuance of certs and only some browsers/apps check via an auditor. (I also don’t understand myself exactly how real-time CT is, but that may just be that I need to understand the SCT mechanism better.) To me these three different components can work together to provide a higher degree of trust: cert pinning to help with the speed of connecting to frequently-visited sites; DANE to help with the first use/key learning issue[1]; and CT to provide another means of checking the cert validity. Comments? [1] And yes, DANE could be used to store entire TLS certs separately, but right now I’m looking at how these pieces could be used together to give the maximum efficiency and security.
DiaaAttia 12y ago
Hello, I would like to help tutors and students by sharing my experience with http://preply.com/en/chinese-by-skype http://preply.com/en/chinese-by-skype I am currently learning Chinese with native speakers over there and the quality presented is excellent and satisfying

205 points by shawndumas 12y ago

It's a good point for Firefox to embed is own certificates. I wonder if there is such unauthorized certs in Firefox manager.

chaitanya 12y ago

It is interesting that when the CNNIC root certificate was added to Firefox, this is exactly what many people had warned against: https://bugzilla.mozilla.org/show_bug.cgi?id=476766 https://bugzilla.mozilla.org/show_bug.cgi?id=476766

ttflee 12y ago
IMHO, had Firefox dared remove CNNIC root cert, Mozilla would already been ousted with their business in China, like Google.

fensipens 12y ago

Goodin can't help but say borderline moronic things every once in a while: Defenders of current system for acquiring and and revoking TLS certificates have recent chafed in response to statements from this author that it's hopelessly broken. Besides remembering that almost all of these critics have a strong financial interest in the way the system works now "chafed" because of this: https://twitter.com/ivanristic/status/578536108662861824 https://twitter.com/ivanristic/status/578536108662861824 So Ristic working for ssllabs automatically disqualifies him from asking the perfectly valid question "What is a better approach, in your opinion?".. You still like your Goodin, tptacek? ;)

blueskin_ 12y ago

The CA system is fundamentally broken. Centralised authorities are bad.

willvarfar 12y ago

Why can the CN registrar sign .com certs? Why aren't national authorities limited to their country's TLD? I'd imagine they'd want this, and the public would want this. Its so obvious, what am I missing?

danyork 12y ago
Any CA can generate a cert for any domain. This is one of the problems with the current CA system.

acd 12y ago

Central certificate authorities were all web users put their trust against money compensation to the CA are a broken security model! Especially in the new internet security era were we have government hackers with almost unlimited budgets. Governments will hack into CAs and issue fake certificates to popular domains that they want to Man in the middle attack and to that we have no protection. I think the solution is a voting mechanism or digital ID. So that the engineer working at Google can sign the certificate with a Corporate Google ID. Central CAs is almost as broken security as credit cards with the card number readable in cleartext on the front of the card.

gislifb 12y ago

Has anyone gone throught the list of root certificates that are trusted in the browsers/OSes and done some homework on them? Would be interesting to see what's behind those authorities and also which certificates they have issued. I see that in the OS X keychain I have 213 "system roots" that are trusted, I wonder how many of them I really need...

PythonicAlpha 12y ago

Action is really needed. A system that can be breached just by any CA company that is more interested in money than in security (also at least one big CAs has a bad history concerning security) is plainly broken. There should at least be a kind of overseer that has the ability to intervene when bad behavior is reported. In the current situation, it is impossible to trust this "system of trust". It just sounds similar as I shall give the keys to my house to the thieves guild to prevent burglaries.

geofft 12y ago
Certificate Transparency is a solution. It's not my favorite solution, but it's far and away my favorite solution that stands a chance of working. http://www.certificate-transparency.org/ http://www.certificate-transparency.org/ This particular bad behavior, like entirely too many other breaches, was (probably) noticed because Google's own browser saw illegitimate but valid Google certificates, and alerted Google through its own channels. CT extends that to any other site that wants to participate. CT also requires that CAs disclose every certificate that's signed, including those signed by intermediates that they give to third parties. This doesn't make legitimate use of intermediates much more onerous, but it makes MITMing-proxy use extremely logistically complicated, even if you felt like telling the whole world you were MITMing certificates.
- itistoday2 12y ago
  > Certificate Transparency is a solution CT would not have prevented these attacks. Google would be exactly where they are right now: knowing who issued cert, and that's it. Short form: https://github.com/okTurtles/dnschain/blob/master/docs/Comparison.md https://github.com/okTurtles/dnschain/blob/master/docs/Compa... Long form: https://blog.okturtles.com/2014/09/the-trouble-with-certificate-transparency/ https://blog.okturtles.com/2014/09/the-trouble-with-certific... (EDIT: How about an honest discussion instead of a downvote? If you disagree, you are welcome to explain why.)
  - geofft 12y ago
    Given the operational difficulty of implementing a transparently-MITMing proxy in a Certificate Transparency regime, I'm not sure you can say with certainty that it wouldn't have prevented this attack. Every time you want to MITM a new site, you need to contact some number of auditors before you can complete the connection. That sounds difficult to implement reliably and quickly enough for a MITM to work. (Not to mention that most off-the-shelf MITM proxies will intentionally not implement this, since the use case for legitimate MITM proxying involves using site-specific CAs, not globally-valid CAs, so you'd have to deploy custom code to go talk to the auditors. And I somehow have doubts that a robust, black-hat MITM proxy solution will emerge, given that it probably will have only a handful of users at any given time.) In any case, it is certainly not a perfect solution. But it is a solution. I've read that okTurtles blog post before. Insofar as it points out that CT has limitations, it's generally right. But the okTurtles scheme is much worse: if a certificate gets compromised, the only recourse is to pick a new website name. I think it's likely that there is no perfect solution here. CT makes no claims for perfection, but it's a pretty good imperfect solution, and I think we need that more than we need a nonexistent perfect solution. BTW: "Resist commenting about being downvoted. It never does any good, and it makes boring reading."

geofft 12y ago

http://googleonlinesecurity.blogspot.com/2015/03/maintaining-digital-certificate-security.html http://googleonlinesecurity.blogspot.com/2015/03/maintaining... is a better URL. (For potential future reference, the current URL is http://arstechnica.com/security/2015/03/google-warns-of-unauthorized-tls-certificates-trusted-by-almost-all-oses/ http://arstechnica.com/security/2015/03/google-warns-of-unau... )

falcolas 12y ago
I disagree, in this case the direct link is not a better URL. The Ars Technica article (as many issues as I have with them) correlates not only the Google alert, but also followup conversations on Twitter and from Mozilla. This kind of correlation (and analysis) is the very definition of adding value added. It also clearly links to the Google blog, so it's hard to accuse them of trying to co-opt Google's content as their own.
ikeboy 12y ago
Ars named the countries that the companies were from. I was half-wondering that when I saw the Google link, I'm happy I saw the ars one after.

GauntletWizard 12y ago

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.

deleted 12y ago

[deleted]

_RPM 12y ago

I've always had the suspicion that my pc had some sketchy certs installed.. what do ya expect from buying a pc with an OS installed from an electronics retailer..right?

Buge 12y ago
I'm pretty sure it's a default install in Windows, so the retailer doesn't really make a difference.
- ptaipale 12y ago
  The retailer doesn't. The vendor (who chooses what to pre-install) does.

_RPM 12y ago

I've always had the suspicion that might my pc had some sketchy certs installed.. what do ya expect from buying a pc with an OS installed from an electronics retailer..right?

pilif 12y ago

Just revoking the intermediates is not enough. This tells the main culprits that it's ok to issue intermediates to do whatever and then deny responsibility as it gets detected. The only possible course of action is to hold the root responsible and to remove them from the trust store. The CA system is fragile enough as it is and only the prospects of immediately going out of business can be any deterrent for CAs not to start doing shady stuff. Yes. Revoking the root is annoying for customers of that root, but I'm sure other CAs will gladly offer a free or really cheap replacement program. And if the affected root is REALLY big, then just pre-announce the revocation for a year or two. Just like what Google is doing with the sha1 certs.

methou 12y ago
I have marked CNNIC root cert untrusted on all of systems I can control. It bothers me sometimes when some providers with "good" reputation uses them, like azure china. I had to manually add the server certificate to trusted list, just to manage my vms. Otherwise, I barely notice the issue. It looks that even CNNIC certs themselves weren't widely deployed, correct me if I'm wrong, most of Chinese sites who wants to employ TLS doesn't do it right, for example, 12306 has its own root and some sites I use daily has a self-signed CA with random input in all of the fields.
- higherpurpose 12y ago
  If you think the company that has agreed to collaborate with a Chinese company to make a different version of Skype (Tom-Skype), for the sole purpose of letting the Chinese government spy on Chinese citizens' communications in real-time, can be "trusted" to not have backdoored cloud services in China, then I have a bridge to sell you. Microsoft has proven again and again that it's willing to make any concessions to the Chinese government if there's the slightest chance of them making an extra percent market share in China. We saw that when Google was hacked by the Chinese government, too. Microsoft was more than happy to agree to all the censorship policies Google didn't, because it meant that maybe possibly that would earn them some market share in China, after Google would be gone - it didn't anyway. Baidu took all that difference Google lost.

Jonhoo 12y ago

FWIW, here's what I just did on my (Arch) Linux machine: $ for f in /etc/ssl/certs/*.pem; do sudo ln -sfn "$f" /etc/ca-certificates/trust-source/blacklist/; done $ sudo update-ca-trust This will block all currently installed CAs (as well as double-block some, but that doesn't really matter). You then need to add them back in. Restart your browser, and go to websites you access frequently (change them to https:// https:// if necessary). Click the (broken) padlock and read off what CA they used; remove the corresponding .pem file from the blacklist directory. Some might be signed by intermediate certs and thus hard to find, but SSL Hopper has a great chain inspection tool at https://www.sslshopper.com/ssl-checker.html https://www.sslshopper.com/ssl-checker.html you can use to identify the topmost CA cert you need to whitelist. After you're done, run "sudo update-ca-trust" again, and restart your browser. All normal sites should work, and you've gotten rid of ~160 root certs. If it's of interest to anyone, here are the ones I whitelisted to get all sites I bothered to try up an running: $ sudo rm DigiCert_* GeoTrust_* Go_Daddy_* GlobalSign_* VeriSign_* StartCom_Certification_Authority* Comodo_* AddTrust_* Thawte_* thawte_Primary_Root_CA* Baltimore_CyberTrust_Root.pem UTN_USERFirst_Hardware_Root_CA.pem Visa_eCommerce_Root.pem $ ls /etc/ssl/certs/*.pem | wc -l 206 $ ls /etc/ca-certificates/trust-source/blacklist/ 163 EDIT: Note that this is not a perfect solution; the CAs you've whitelisted could still go bad, and you'll need to blacklist any new CA certs that are added with subsequent ca-certificates updates. But it's a start.

kpcyrd 12y ago
Be careful, this has no effect if you're using firefox/iceweasel. They bring their own set of trusted CAs and ignore all changes on the OS trust store.
pyre 12y ago
You've said the start by blacklisting all SSL, then to inspect the SSL chain using SSL Shopper, but the link to SSL Shopper is using https. So (at least the first time), you need to inspect yet another SSL cert before you can inspect the other SSL cert you were looking at. :P (FYI, looks like SSL Shopper uses GoDaddy for SSL)

methou 12y ago

The day has come.

nly 12y ago

If they implemented and enabled DANE in Chromium then we could detect and render harmless this miss-issuance for our domains via PKIX-TA Certificate Authority Constraints instead of playing Whac-A-Mole

danyork 12y ago

So what do we do to fix the broken CA system? Particularly in a case where a bogus certificate is issued by an intermediate CA that rolls up to a root CA that is included in all the major browsers. It seems to me that we have several building blocks available and it may be a combination we need: 1. CERTIFICATE PINNING (HPKP) - example: http://tools.ietf.org/html/draft-ietf-websec-key-pinning-21 http://tools.ietf.org/html/draft-ietf-websec-key-pinning-21 - if a browser had previously pinned the certs of affected sites then it would have known that it was going to bogus sites and could have displayed a warning or prevented the user from going to those sites. The challenge with pinning is that somehow you have to learn what to pin before you visit a site, either by having the pinset or certs pre-loaded into the app/browser or simply by doing Trust On First Use (TOFU). Additionally, if the first use is to the site controlled by an attacker, the cert that gets pinned in the browser could in fact be the attacker's cert, which could make recovery difficult. Which brings us to... 2. DANE/DNSSEC - http://www.internetsociety.org/deploy360/resources/dane/ http://www.internetsociety.org/deploy360/resources/dane/ - with DANE (RFC 6698) you put a fingerprint (or an entire cert) into a TLSA record in DNS and then sign that with DNSSEC. A browser or app that supported DANE could deal with the TOFU issue by doing a DANE check to verify the cert that it is receiving from the web server. This would then effectively bootstrap the cert pinning process by providing a way to test the validity of the cert. Because the DANE TLSA records are entered by the owner/operator of the domain and then through DS records are tied into a validated chain-of-trust up to the root of DNS, it would be difficult for an attacker to subvert this with his/her malicious TLSA records. But we have a third layer to help... 3. CERTIFICATE TRANSPARENCY (CT) - http://www.certificate-transparency.org/ http://www.certificate-transparency.org/ - CT provides a way to log all the issued certs and have browsers/apps check those logs through an auditor. When the browser gets the TLS cert, it also gets a signed cert timestamp (SCT) and can use that through an auditor component to check if the cert is valid. The challenge is that right now only some CAs log issuance of certs and only some browsers/apps check via an auditor. (I also don’t understand myself exactly how real-time CT is, but that may just be that I need to understand the SCT mechanism better.) To me these three different components can work together to provide a higher degree of trust: cert pinning to help with the speed of connecting to frequently-visited sites; DANE to help with the first use/key learning issue[1]; and CT to provide another means of checking the cert validity. Comments? [1] And yes, DANE could be used to store entire TLS certs separately, but right now I’m looking at how these pieces could be used together to give the maximum efficiency and security.

DiaaAttia 12y ago

Hello, I would like to help tutors and students by sharing my experience with http://preply.com/en/chinese-by-skype http://preply.com/en/chinese-by-skype I am currently learning Chinese with native speakers over there and the quality presented is excellent and satisfying