10 ms·

Maintaining Digital Certificate Security

107 points by cleverjake 12y ago

tptacek 12y ago
What seems to have happened here: An Egyptian telecom company, MCS Holdings, contracted with CNNIC, the Chinese national Internet authority, to obtain a CA=TRUE certificate for use in their internal enterprise proxy --- ostensibly for use only with MCS's own hostnames. Users of MCS traversed that proxy to get to Google, at which point the proxy dutifully generated a (fake) Google certificate to bypass TLS for that connection. Google noticed. Internal enterprise MITM proxy sounds creepy but isn't. There's a bunch of good reasons why a company would need to decrypt TLS traffic leaving their own network. But enterprises don't need delegated CA=TRUE certificates to accomplish this. They can just roll their own self-signed root CA=TRUE certificate and built it into their machines. There is no reason a CA should need to put the entire Internet at risk solely for the convenience of a single company's IT operations. A Chicago company called Trustwave did something similar a few years back. Are they still an HTTPS CA?
- Stefan-H 12y ago
  Trustwave is still in the Mozilla CA bundle: https://wiki.mozilla.org/CA:IncludedCAs https://wiki.mozilla.org/CA:IncludedCAs
  - bradleyjg 12y ago
    At the end of the bug discussion here: https://bugzilla.mozilla.org/show_bug.cgi?id=724929 https://bugzilla.mozilla.org/show_bug.cgi?id=724929 it was decided to give Trustwave a reprieve. Mozilla policy was updated to explicitly forbid such usage, and each of the CA was required to verify that they were complying with the new policy or state when they would come into compliance. CNNIC did so here: https://docs.google.com/spreadsheet/pub?key=0Ah-tHXMAwqU3dGxsWlZEdGFDaW9JTlNTUGxBNWhqSlE&output=html https://docs.google.com/spreadsheet/pub?key=0Ah-tHXMAwqU3dGx... Kathleen Wilson's comment on the bug was: https://bugzilla.mozilla.org/show_bug.cgi?id=724929#c66 https://bugzilla.mozilla.org/show_bug.cgi?id=724929#c66 "My intent is to make it clear that this type of behavior will not be tolerated for subCAs chaining to roots in NSS, give all CAs fair warning and a grace period, and state the consequences if such behavior is found after that grace period." However, over 14th months later when it came out the ANSSI (aka the French government) was doing the exact same thing, rather than revoking the root certificate Mozilla decided to limit them to issuing certificates to: .fr, .gp, .gf, .mq, .re, .yt, .pm, .bl, .mf, .wf, .pf, .nc, .tf which AFAICT essentially acquiesces in MitM French firefox users that go to French websites. I wonder if the response will be the same here.
    - kijin 12y ago
      > Mozilla decided to limit them to issuing certificates to: .fr, .gp, .gf, .mq, .re, .yt, .pm, .bl, .mf, .wf, .pf, .nc, .tf Is there any way to do the same, manually, for the other "national" CAs? I woudln't mind if CNNIC handed out a certificate for every .cn domain out there, but if they ever try to sign one for an Egyptian entity (or even worse, a .com domain), I want to see a big red warning. Ditto for the Japanese and Taiwanese governments, which Firefox also seems to trust unconditionally. I actually do this to some extent, as I don't quite trust the NIC of my own government. I told my browser not to trust it, so whenever I try to visit a government website, I get a big red warning. I override the warning after confirming that I am indeed visiting a government website protected with a government certificate. But if the government NIC ever tried to show me a certificate for a non-government website, I would know immediately. This works, but it's inconvenient, so I'd love to be able to restrict any given CA to subdomains of specific TLDs and/or second-level domains.
  - tomjen3 12y ago
    So is the Chinese who signed the certificate, probably. Too big to fail and all that jazz.
- sekasi 12y ago
  Would you mind elaborating on the good reasons for MITM your company web traffic? I'm not being facetious, genuinely curious.
  - tptacek 12y ago
    For instance, if you are a company that handles confidential medical information (any health care organization, many insurers, every employee benefits management organization, &c), you may be required to have controls in place to ensure that nobody uses your Internet connection to exfiltrate people's PII through Google Mail. Similarly, many investment banks and financial information firms have strict requirements to monitor all communications owing to SEC rules and insider trading regulation.
    - mjs 12y ago
      Is there any way to detect that you're being MITM'd?
      - bradleyjg 12y ago
        You check the certificate chain and compare it to a clean version. Obviously that's going to be a solution limited to very savvy users.
      - tptacek 12y ago
        That's part of the point of certificate pinning.
      - aslewofmice 12y ago
        Would love to know this as well. I only have a high level understanding of the purpose of CA Certs, but beyond that I'm lost. Ignorant questions ahoy: 1. Using Chrome, would you have to manually accept the MITM certificate? 2. Could such a certificate be valid across multiple domains? 3. Would it pose any threat to the computer if it was moved from the MITM network to an outside network? 4. What kind of potential problems could occur if I issued a self-signed certificate for my network?
- jlgaddis 12y ago
  > But enterprises don't need delegated CA=TRUE certificates to accomplish this. They can just roll their own self-signed root CA=TRUE certificate and built it into their machines. There is no reason a CA should need to put the entire Internet at risk solely for the convenience of a single company's IT operations. Doing it this way, however, means that they don't need to worry about pushing their self-signed certificate out to all their machines, right? That could be done easily with group policies on Windows machines which would take care of, at least, Internet Explorer. I haven't used a Windows machine in a long time, though, so I'll ask: do the other major browsers use the built-in certificate store? If not, they'd still have to address the problem of getting their self-signed certificate "trusted" by Firefox and Chrome, for example.
  - gcp 12y ago
    Firefox does not use the built-in certificate store. Mozilla has their own trusted CA list.
  - NeutronBoy 12y ago
    Chrome does, Firefox doesn't. I'm not sure if there's a way to mass-push certs to FF with AD
    - omh 12y ago
      Not directly via AD. But you can add it to the certificate database in the template Firefox profile.
- MichaelGG 12y ago
  Signing another "CA=TRUE" cert seems like it should be a very restricted and audited operation, right? Is it out of the question to say that all such certs should be cleared by 3rd parties (like Mozilla and MS), on pain of revocation? Or is there a large use case outside of CA infrastructure I'm unaware of? Google's response here seems a bit weak.
  - JoshTriplett 12y ago
    I would agree; there's really no reason that all major browsers couldn't ship with a complete list of all acceptable CA=TRUE certificates, intermediate or otherwise.
    - yuhong 12y ago
      Unlikely and would cause problems. Parent was suggesting that they should be cleared separately without having to update browsers. I like the certificate transparency idea better though, and I wonder if it is possible to refuse new certs via public endpoints but allow certs to be manually added to the logs and SCTs to be manually issued, in case going that far is needed.
      - JoshTriplett 12y ago
        What problems, precisely? Sure, it would prevent current CAs from selling sub-CA certificates without coordinating with browser vendors. That's the point. What's a legitimate use case for doing so?
        yuhong 12y ago
        Yes, but the point is that this "coordinating" can be done without users having to update browsers themselves.
        JoshTriplett 12y ago
        All the major browsers have automatic updates these days. And if the coordination doesn't include a browser whitelist, it has no teeth.
- djrogers 12y ago
  > Users of MCS traversed that proxy to get to Google, at which point the proxy dutifully generated a (fake) Google certificate to bypass TLS for that connection. Google noticed. I'm curious about the mechanism of Google noticing - was Chrome side-channeling information about it's cert to Google? Because if it was a true MITM proxy, google would never have talked to the browser directly to know what cert the browser was being presented. That's kinda how the whole MITM thing is dangerous - it's invisible to both sides if done correctly...
  - iancarroll 12y ago
    Google Chrome automatically reports back to Google if a certificate appears for Google and it is not issued by Google's own intermediary. It also blocks it from ever loading via HPKP.
  - mdavidn 12y ago
    Chrome ships with a list of CAs allowed to issue Google certificates. If Chrome encounters a Google certificate signed by some other root authority, it phones home. http://blog.chromium.org/2011/06/new-chromium-security-features-june.html http://blog.chromium.org/2011/06/new-chromium-security-featu...
- jsprogrammer 12y ago
  If a company can 'put the entire Internet at risk', even if 'solely for the convenience of [their] IT operations', the system is fundamentally flawed.
  - cgtyoder 12y ago
    As you can see, there is a lot of trust that is given to CAs. The whole cert security depends on it. The only (current) real remedy is the nuclear option - removing those CA's certs from the major browsers. Then the other side (Chinese browser vendors) can retaliate, of course. So negotiation is required to maintain detente.
    - itistoday2 12y ago
      > The only (current) real remedy is the nuclear option Blockchain-based solutions like Namecoin & DNSChain would have prevented this attack without forcing people to rely on untrusted third-parties (if Google stored their domain info in a blockchain). We compare various mechanisms here: https://github.com/okTurtles/dnschain/blob/master/docs/Comparison.md https://github.com/okTurtles/dnschain/blob/master/docs/Compa... EDIT: Not sure why this comment is getting downvoted. Maybe some folks don't want this problem to be fixed? :-\
      - nosuchthing 12y ago
        Derivatives of Moxie Marlinspike's Convergence cert plugin that allows you to assign your own trust authorities for verifying signatures. [0] [0] https://github.com/moxie0/Convergence/network https://github.com/moxie0/Convergence/network
        itistoday2 12y ago
        > Derivatives of Moxie Marlinspike's Convergence cert plugin that allows you to assign your own trust authorities for verifying signatures. [0] The only derivative of Convergence that actually addresses the problems with Convergence (ironically), is FreeSpeechMe, which btw, relies on Namecoin's blockchain. But downvote me again for pointing out facts. lol.
- georgerobinson 12y ago
  If you're on a machine which has self-signed root certificates in its trusted store does this mean that all bets are off? Can you achieve authentication, integrity and confidentiality despite having an adversarial root certificate on your machine (for example, if all network connections go via proxy which do MITM on TLS connections and DPI)?
- deleted 12y ago
  [deleted]
- mvanotti 12y ago
  In the blog post it says that CNNIC issued the CA=TRUE on the basis that MCS H only use it for domains that they have registered.. Wouldn't it be better to just issue a CA cert with name constrains extensions? Why do we have that extension if nobody uses it :( ?
Stefan-H 12y ago
At this point I feel like we need to simply remove Chinese root CAs from trust stores and have user's opt-in to allowing certificates issued from china. I realize that any CA can be mismanaged, but the risk of Chinese government hands in things like this seem too high to me. Edit: I have no delusions that this is not happening in the US, it is simply that as someone in the US, I don't have any options to lop off CAs that the US could influence. I can however make the decision to not trust some foreign CAs entirelly.
- mike_hearn 12y ago
  You can always remove CNNIC from your own trust store. Saying they should be removed from all trust stores would rather annoy people actually in China, I'd assume. I wonder if certificate transparency could be mandated for intermediate certificates sooner than a full DV rollout could. It seems some CAs can't quite resist bending the rules when a sweet contract is dangled in front of their faces. It makes me wonder how much CNNIC was being paid to do this. Given that MCS Holdings sells "security products" it makes me wonder if this was an attempt to do or prepare to do bulk SSL stripping. I guess the blog post says there was no evidence of abuse though, so I guess not.
  - itistoday2 12y ago
    > I wonder if certificate transparency could be mandated for intermediate certificates sooner than a full DV rollout could. It should be mentioned that Certificate Transparency would not have prevented this attack (nor any other such attack). Google has nothing to gain from CT beyond where they are right now: knowing who issued the cert. Details: https://blog.okturtles.com/2014/09/the-trouble-with-certificate-transparency/ https://blog.okturtles.com/2014/09/the-trouble-with-certific... TLDR: https://github.com/okTurtles/dnschain/blob/master/docs/Comparison.md#certificate-transparency https://github.com/okTurtles/dnschain/blob/master/docs/Compa...
    - yuhong 12y ago
      Not this particular attack, as this was a test intermediate only valid for 2 weeks, but the attack was limited to an internal corporate network. For other cases it would allow browser vendor to demand audit reports for example.
jlgaddis 12y ago
# remove-cnnic-root-ca-certificate.pp (only tested on ubuntu 14.04) file { 'CNNIC_ROOT.crt': path => '/usr/share/ca-certificates/mozilla/CNNIC_ROOT.crt', ensure => absent, } file { '895cad1a.0': path => '/etc/ssl/certs/895cad1a.0', ensure => absent, } file { 'bd1910d4.0': path => '/etc/ssl/certs/bd1910d4.0', ensure => absent, } file { 'CNNIC_ROOT.pem': path => '/etc/ssl/certs/CNNIC_ROOT.pem', ensure => absent, } (N.B.: Yes, I know that doesn't completely take care of the problem. I manually "distrusted" it in Chromium and Firefox as well.)
- tveita 12y ago
  If correctly disabled https://www1.cnnic.cn/ https://www1.cnnic.cn/ should give a certificate error.
mcherm 12y ago
So, Google's page on this promotes a project for certificate transparency. I am not familiar with this project; does anyone here know more about it and if so can you comment on whether you think it's a good idea for the overall ecosystem.
- mike_hearn 12y ago
  CT is a simple idea. Currently, it's possible for certificates to be issued privately. The PKI was designed to scale (and scale it does), so there is no requirement that a certificate be downloaded from some trusted source: an SSL server can provide the client with a certificate chain that acts as a proof that a public key is owned by a particular named entity. That has some advantages, most obviously, scalability and robustness. It also has one giant disadvantage: the only way to catch misbehaviour is to actually find a bogus certificate being used in the wild. Certificate transparency is Google's plan to fix this. The idea is to evolve the PKI in a backwards compatible way. It creates public logs in which every certificate is meant to be registered. The certificates (or SSL handshakes, or a few other things) can then have a short mathematical proof embedded in them that the certificate was logged. If the log proof isn't present then browsers remove the security indicators in order to apply pressure to people to get their certificates logged. It's supposed to be done by CAs so most SSL users should never notice any of this is happening. Once certificates are being logged publicly the idea is anyone can do data mining over the log, for example to find certificates issued for their own website that they know they didn't request. Thus it allows crowdsourced policing of the CA system. Violations of the rules could be detected much faster. Currently however only Chrome implements CT, and only for EV certs (the ones that make the address bar green), and the majority of CAs have been ignoring it, although the big fish are taking part. The customers of the smaller CAs that are pretending CT isn't happening will get a nasty surprise once Chrome stops treating their certificate as EV.
  - iancarroll 12y ago
    Small nitpick: Chrome implements CT for all certificates and shows its status, however they only currently plan to downgrade an EV certificate to a normal certificate. Firefox has an open bug for implementation[1] but it's inactive for whatever reason. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=944175 https://bugzilla.mozilla.org/show_bug.cgi?id=944175
0x0 12y ago
How can they possibly defend not removing CNNIC from the roots after this? SSL is broken and nobody is lifting a finger :(
- Buge 12y ago
  Untrusting CNNIC wouldn't really "fix" it. There are hundreds of trusted CAs, and any of them could do something like this.
  - 0x0 12y ago
    Could, but would? At least ban the ones that are proven to be untrustworthy. Otherwise the entire concept of a trust store is a joke and a racket to print money (certificates)
  - MichaelGG 12y ago
    Not removing CNNIC just says that other CAs won't be punished, either. Like Comodo.[1] Browsers should start considering scoping CAs by default. If CNNIC signs, say, a Mexican domain, that might be cause for suspicion. It's a bit more complicated since .com and others are sorta generic. But there's gotta be something that can limit exposure for many customers. How many US users often run into CNNIC, or those South American CAs? 1: On one of their sales calls, I told them they failed at the one thing they were supposed to do as a CA. Without missing a beat, the guy shifted to trying to sell me antivirus software.
  - dragonwriter 12y ago
    Adopting a zero-tolerance policy for CAs that are bad actors (including those that allow others to have their full power who themselves act as bad actors) and removing their root certificates from trust stores would create a substantial disincentive for CAs to be bad actors.
    - PhantomGremlin 12y ago
      Yeah, I can't believe the "oh, that's OK, a silly bureaucratic snafu, boys will be boys" response from Google. But at least they told us, they didn't sweep it under the rug. I would have preferred the Pulp Fiction version. Google should have instead said to CNNIC: You hear me talkin', hillbilly boy? I ain't through with you by a damn sight. I'ma get medieval on your ass.
yuhong 12y ago
Fortunately this is only a test CA that will expire at beginning of April.
iancarroll 12y ago
This is actually solid grounds for removal in all trust stores, honestly. They did numerous things wrong (from what I am reading here): - The CA must have had some warning that it wasn't being loaded onto a HSM - It was never verified the CSR/key was generated on a HSM (!!!) - The auditors did not oversee the key being generated (this is typical for roots, although not for intermediaries) - If this subordinate was in operation for >1yr, how was this not caught in an audit? and you can't load a certificate off of a HSM, so I'd argue the CA is entirely at fault here.
- yuhong 12y ago
  The fourth point is not true, I looked at the intermediate myself. In fact the test intermediate is only days old at the time of the writing and last less than a month before it expires.
click170 12y ago
Is anyone else frustrated after trying to load this page on a mobile device? I zoom in to read the text and when I try to slide the screen over, it interprets that as me wanting to go to the next page. No, I wanted to read the text on THIS page.
qeorge 12y ago
Honest question: as a United States internet user, is there any practical reason I need to have a root certificate from the Chinese national Internet authority installed? Corollary, is there a short list of CAs that folks around here trust more than average? Is there any value in such a whitelist, or are all CAs so rotten it doesn't much matter?
- kjs3 12y ago
  If you regularly visit Chinese sites that use HTTPS.
  - lucaspiller 12y ago
    ...that use this CA. I regularly use Alibaba, but their certificates are signed by "VeriSign Class 3 Secure Server CA - G3".
- kijin 12y ago
  There was a bit of controversy a few years ago when Mozilla added CNNIC to Firefox's list of trusted CAs. I removed CNNIC from my browser shortly afterwards. No problem so far. I don't think you'll have much problem even if you only trusted a few U.S. megacorporations, such as Verisign, Comodo, GeoTrust, GoDaddy, etc. They're no more trustworthy than the rest, but at least they're much more widely used than some government agency of a country you have nothing to do with.
colinbartlett 12y ago
What can a site administrator do today to combat these kinds of flaws? Is there some certificate pinning technology (I don't fully understand what that is) I can use on my own sites now to push in the right direction? I try to be an early adopter of such practices such as using SSL all the time on all my sites.

107 points by cleverjake 12y ago

What seems to have happened here: An Egyptian telecom company, MCS Holdings, contracted with CNNIC, the Chinese national Internet authority, to obtain a CA=TRUE certificate for use in their internal enterprise proxy --- ostensibly for use only with MCS's own hostnames. Users of MCS traversed that proxy to get to Google, at which point the proxy dutifully generated a (fake) Google certificate to bypass TLS for that connection. Google noticed. Internal enterprise MITM proxy sounds creepy but isn't. There's a bunch of good reasons why a company would need to decrypt TLS traffic leaving their own network. But enterprises don't need delegated CA=TRUE certificates to accomplish this. They can just roll their own self-signed root CA=TRUE certificate and built it into their machines. There is no reason a CA should need to put the entire Internet at risk solely for the convenience of a single company's IT operations. A Chicago company called Trustwave did something similar a few years back. Are they still an HTTPS CA?

Stefan-H 12y ago
Trustwave is still in the Mozilla CA bundle: https://wiki.mozilla.org/CA:IncludedCAs https://wiki.mozilla.org/CA:IncludedCAs
- bradleyjg 12y ago
  At the end of the bug discussion here: https://bugzilla.mozilla.org/show_bug.cgi?id=724929 https://bugzilla.mozilla.org/show_bug.cgi?id=724929 it was decided to give Trustwave a reprieve. Mozilla policy was updated to explicitly forbid such usage, and each of the CA was required to verify that they were complying with the new policy or state when they would come into compliance. CNNIC did so here: https://docs.google.com/spreadsheet/pub?key=0Ah-tHXMAwqU3dGxsWlZEdGFDaW9JTlNTUGxBNWhqSlE&output=html https://docs.google.com/spreadsheet/pub?key=0Ah-tHXMAwqU3dGx... Kathleen Wilson's comment on the bug was: https://bugzilla.mozilla.org/show_bug.cgi?id=724929#c66 https://bugzilla.mozilla.org/show_bug.cgi?id=724929#c66 "My intent is to make it clear that this type of behavior will not be tolerated for subCAs chaining to roots in NSS, give all CAs fair warning and a grace period, and state the consequences if such behavior is found after that grace period." However, over 14th months later when it came out the ANSSI (aka the French government) was doing the exact same thing, rather than revoking the root certificate Mozilla decided to limit them to issuing certificates to: .fr, .gp, .gf, .mq, .re, .yt, .pm, .bl, .mf, .wf, .pf, .nc, .tf which AFAICT essentially acquiesces in MitM French firefox users that go to French websites. I wonder if the response will be the same here.
  - kijin 12y ago
    > Mozilla decided to limit them to issuing certificates to: .fr, .gp, .gf, .mq, .re, .yt, .pm, .bl, .mf, .wf, .pf, .nc, .tf Is there any way to do the same, manually, for the other "national" CAs? I woudln't mind if CNNIC handed out a certificate for every .cn domain out there, but if they ever try to sign one for an Egyptian entity (or even worse, a .com domain), I want to see a big red warning. Ditto for the Japanese and Taiwanese governments, which Firefox also seems to trust unconditionally. I actually do this to some extent, as I don't quite trust the NIC of my own government. I told my browser not to trust it, so whenever I try to visit a government website, I get a big red warning. I override the warning after confirming that I am indeed visiting a government website protected with a government certificate. But if the government NIC ever tried to show me a certificate for a non-government website, I would know immediately. This works, but it's inconvenient, so I'd love to be able to restrict any given CA to subdomains of specific TLDs and/or second-level domains.
- tomjen3 12y ago
  So is the Chinese who signed the certificate, probably. Too big to fail and all that jazz.
sekasi 12y ago
Would you mind elaborating on the good reasons for MITM your company web traffic? I'm not being facetious, genuinely curious.
- tptacek 12y ago
  For instance, if you are a company that handles confidential medical information (any health care organization, many insurers, every employee benefits management organization, &c), you may be required to have controls in place to ensure that nobody uses your Internet connection to exfiltrate people's PII through Google Mail. Similarly, many investment banks and financial information firms have strict requirements to monitor all communications owing to SEC rules and insider trading regulation.
  - mjs 12y ago
    Is there any way to detect that you're being MITM'd?
    - bradleyjg 12y ago
      You check the certificate chain and compare it to a clean version. Obviously that's going to be a solution limited to very savvy users.
    - tptacek 12y ago
      That's part of the point of certificate pinning.
    - aslewofmice 12y ago
      Would love to know this as well. I only have a high level understanding of the purpose of CA Certs, but beyond that I'm lost. Ignorant questions ahoy: 1. Using Chrome, would you have to manually accept the MITM certificate? 2. Could such a certificate be valid across multiple domains? 3. Would it pose any threat to the computer if it was moved from the MITM network to an outside network? 4. What kind of potential problems could occur if I issued a self-signed certificate for my network?
jlgaddis 12y ago
> But enterprises don't need delegated CA=TRUE certificates to accomplish this. They can just roll their own self-signed root CA=TRUE certificate and built it into their machines. There is no reason a CA should need to put the entire Internet at risk solely for the convenience of a single company's IT operations. Doing it this way, however, means that they don't need to worry about pushing their self-signed certificate out to all their machines, right? That could be done easily with group policies on Windows machines which would take care of, at least, Internet Explorer. I haven't used a Windows machine in a long time, though, so I'll ask: do the other major browsers use the built-in certificate store? If not, they'd still have to address the problem of getting their self-signed certificate "trusted" by Firefox and Chrome, for example.
- gcp 12y ago
  Firefox does not use the built-in certificate store. Mozilla has their own trusted CA list.
- NeutronBoy 12y ago
  Chrome does, Firefox doesn't. I'm not sure if there's a way to mass-push certs to FF with AD
  - omh 12y ago
    Not directly via AD. But you can add it to the certificate database in the template Firefox profile.
MichaelGG 12y ago
Signing another "CA=TRUE" cert seems like it should be a very restricted and audited operation, right? Is it out of the question to say that all such certs should be cleared by 3rd parties (like Mozilla and MS), on pain of revocation? Or is there a large use case outside of CA infrastructure I'm unaware of? Google's response here seems a bit weak.
- JoshTriplett 12y ago
  I would agree; there's really no reason that all major browsers couldn't ship with a complete list of all acceptable CA=TRUE certificates, intermediate or otherwise.
  - yuhong 12y ago
    Unlikely and would cause problems. Parent was suggesting that they should be cleared separately without having to update browsers. I like the certificate transparency idea better though, and I wonder if it is possible to refuse new certs via public endpoints but allow certs to be manually added to the logs and SCTs to be manually issued, in case going that far is needed.
    - JoshTriplett 12y ago
      What problems, precisely? Sure, it would prevent current CAs from selling sub-CA certificates without coordinating with browser vendors. That's the point. What's a legitimate use case for doing so?
      - yuhong 12y ago
        Yes, but the point is that this "coordinating" can be done without users having to update browsers themselves.
        JoshTriplett 12y ago
        All the major browsers have automatic updates these days. And if the coordination doesn't include a browser whitelist, it has no teeth.
djrogers 12y ago
> Users of MCS traversed that proxy to get to Google, at which point the proxy dutifully generated a (fake) Google certificate to bypass TLS for that connection. Google noticed. I'm curious about the mechanism of Google noticing - was Chrome side-channeling information about it's cert to Google? Because if it was a true MITM proxy, google would never have talked to the browser directly to know what cert the browser was being presented. That's kinda how the whole MITM thing is dangerous - it's invisible to both sides if done correctly...
- iancarroll 12y ago
  Google Chrome automatically reports back to Google if a certificate appears for Google and it is not issued by Google's own intermediary. It also blocks it from ever loading via HPKP.
- mdavidn 12y ago
  Chrome ships with a list of CAs allowed to issue Google certificates. If Chrome encounters a Google certificate signed by some other root authority, it phones home. http://blog.chromium.org/2011/06/new-chromium-security-features-june.html http://blog.chromium.org/2011/06/new-chromium-security-featu...
jsprogrammer 12y ago
If a company can 'put the entire Internet at risk', even if 'solely for the convenience of [their] IT operations', the system is fundamentally flawed.
- cgtyoder 12y ago
  As you can see, there is a lot of trust that is given to CAs. The whole cert security depends on it. The only (current) real remedy is the nuclear option - removing those CA's certs from the major browsers. Then the other side (Chinese browser vendors) can retaliate, of course. So negotiation is required to maintain detente.
  - itistoday2 12y ago
    > The only (current) real remedy is the nuclear option Blockchain-based solutions like Namecoin & DNSChain would have prevented this attack without forcing people to rely on untrusted third-parties (if Google stored their domain info in a blockchain). We compare various mechanisms here: https://github.com/okTurtles/dnschain/blob/master/docs/Comparison.md https://github.com/okTurtles/dnschain/blob/master/docs/Compa... EDIT: Not sure why this comment is getting downvoted. Maybe some folks don't want this problem to be fixed? :-\
    - nosuchthing 12y ago
      Derivatives of Moxie Marlinspike's Convergence cert plugin that allows you to assign your own trust authorities for verifying signatures. [0] [0] https://github.com/moxie0/Convergence/network https://github.com/moxie0/Convergence/network
      - itistoday2 12y ago
        > Derivatives of Moxie Marlinspike's Convergence cert plugin that allows you to assign your own trust authorities for verifying signatures. [0] The only derivative of Convergence that actually addresses the problems with Convergence (ironically), is FreeSpeechMe, which btw, relies on Namecoin's blockchain. But downvote me again for pointing out facts. lol.
georgerobinson 12y ago
If you're on a machine which has self-signed root certificates in its trusted store does this mean that all bets are off? Can you achieve authentication, integrity and confidentiality despite having an adversarial root certificate on your machine (for example, if all network connections go via proxy which do MITM on TLS connections and DPI)?
deleted 12y ago
[deleted]
mvanotti 12y ago
In the blog post it says that CNNIC issued the CA=TRUE on the basis that MCS H only use it for domains that they have registered.. Wouldn't it be better to just issue a CA cert with name constrains extensions? Why do we have that extension if nobody uses it :( ?

Stefan-H 12y ago

At this point I feel like we need to simply remove Chinese root CAs from trust stores and have user's opt-in to allowing certificates issued from china. I realize that any CA can be mismanaged, but the risk of Chinese government hands in things like this seem too high to me. Edit: I have no delusions that this is not happening in the US, it is simply that as someone in the US, I don't have any options to lop off CAs that the US could influence. I can however make the decision to not trust some foreign CAs entirelly.

mike_hearn 12y ago
You can always remove CNNIC from your own trust store. Saying they should be removed from all trust stores would rather annoy people actually in China, I'd assume. I wonder if certificate transparency could be mandated for intermediate certificates sooner than a full DV rollout could. It seems some CAs can't quite resist bending the rules when a sweet contract is dangled in front of their faces. It makes me wonder how much CNNIC was being paid to do this. Given that MCS Holdings sells "security products" it makes me wonder if this was an attempt to do or prepare to do bulk SSL stripping. I guess the blog post says there was no evidence of abuse though, so I guess not.
- itistoday2 12y ago
  > I wonder if certificate transparency could be mandated for intermediate certificates sooner than a full DV rollout could. It should be mentioned that Certificate Transparency would not have prevented this attack (nor any other such attack). Google has nothing to gain from CT beyond where they are right now: knowing who issued the cert. Details: https://blog.okturtles.com/2014/09/the-trouble-with-certificate-transparency/ https://blog.okturtles.com/2014/09/the-trouble-with-certific... TLDR: https://github.com/okTurtles/dnschain/blob/master/docs/Comparison.md#certificate-transparency https://github.com/okTurtles/dnschain/blob/master/docs/Compa...
  - yuhong 12y ago
    Not this particular attack, as this was a test intermediate only valid for 2 weeks, but the attack was limited to an internal corporate network. For other cases it would allow browser vendor to demand audit reports for example.

jlgaddis 12y ago

# remove-cnnic-root-ca-certificate.pp (only tested on ubuntu 14.04) file { 'CNNIC_ROOT.crt': path => '/usr/share/ca-certificates/mozilla/CNNIC_ROOT.crt', ensure => absent, } file { '895cad1a.0': path => '/etc/ssl/certs/895cad1a.0', ensure => absent, } file { 'bd1910d4.0': path => '/etc/ssl/certs/bd1910d4.0', ensure => absent, } file { 'CNNIC_ROOT.pem': path => '/etc/ssl/certs/CNNIC_ROOT.pem', ensure => absent, } (N.B.: Yes, I know that doesn't completely take care of the problem. I manually "distrusted" it in Chromium and Firefox as well.)

tveita 12y ago
If correctly disabled https://www1.cnnic.cn/ https://www1.cnnic.cn/ should give a certificate error.

mcherm 12y ago

So, Google's page on this promotes a project for certificate transparency. I am not familiar with this project; does anyone here know more about it and if so can you comment on whether you think it's a good idea for the overall ecosystem.

mike_hearn 12y ago
CT is a simple idea. Currently, it's possible for certificates to be issued privately. The PKI was designed to scale (and scale it does), so there is no requirement that a certificate be downloaded from some trusted source: an SSL server can provide the client with a certificate chain that acts as a proof that a public key is owned by a particular named entity. That has some advantages, most obviously, scalability and robustness. It also has one giant disadvantage: the only way to catch misbehaviour is to actually find a bogus certificate being used in the wild. Certificate transparency is Google's plan to fix this. The idea is to evolve the PKI in a backwards compatible way. It creates public logs in which every certificate is meant to be registered. The certificates (or SSL handshakes, or a few other things) can then have a short mathematical proof embedded in them that the certificate was logged. If the log proof isn't present then browsers remove the security indicators in order to apply pressure to people to get their certificates logged. It's supposed to be done by CAs so most SSL users should never notice any of this is happening. Once certificates are being logged publicly the idea is anyone can do data mining over the log, for example to find certificates issued for their own website that they know they didn't request. Thus it allows crowdsourced policing of the CA system. Violations of the rules could be detected much faster. Currently however only Chrome implements CT, and only for EV certs (the ones that make the address bar green), and the majority of CAs have been ignoring it, although the big fish are taking part. The customers of the smaller CAs that are pretending CT isn't happening will get a nasty surprise once Chrome stops treating their certificate as EV.
- iancarroll 12y ago
  Small nitpick: Chrome implements CT for all certificates and shows its status, however they only currently plan to downgrade an EV certificate to a normal certificate. Firefox has an open bug for implementation[1] but it's inactive for whatever reason. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=944175 https://bugzilla.mozilla.org/show_bug.cgi?id=944175

0x0 12y ago

How can they possibly defend not removing CNNIC from the roots after this? SSL is broken and nobody is lifting a finger :(

Buge 12y ago
Untrusting CNNIC wouldn't really "fix" it. There are hundreds of trusted CAs, and any of them could do something like this.
- 0x0 12y ago
  Could, but would? At least ban the ones that are proven to be untrustworthy. Otherwise the entire concept of a trust store is a joke and a racket to print money (certificates)
- MichaelGG 12y ago
  Not removing CNNIC just says that other CAs won't be punished, either. Like Comodo.[1] Browsers should start considering scoping CAs by default. If CNNIC signs, say, a Mexican domain, that might be cause for suspicion. It's a bit more complicated since .com and others are sorta generic. But there's gotta be something that can limit exposure for many customers. How many US users often run into CNNIC, or those South American CAs? 1: On one of their sales calls, I told them they failed at the one thing they were supposed to do as a CA. Without missing a beat, the guy shifted to trying to sell me antivirus software.
- dragonwriter 12y ago
  Adopting a zero-tolerance policy for CAs that are bad actors (including those that allow others to have their full power who themselves act as bad actors) and removing their root certificates from trust stores would create a substantial disincentive for CAs to be bad actors.
  - PhantomGremlin 12y ago
    Yeah, I can't believe the "oh, that's OK, a silly bureaucratic snafu, boys will be boys" response from Google. But at least they told us, they didn't sweep it under the rug. I would have preferred the Pulp Fiction version. Google should have instead said to CNNIC: You hear me talkin', hillbilly boy? I ain't through with you by a damn sight. I'ma get medieval on your ass.

yuhong 12y ago

Fortunately this is only a test CA that will expire at beginning of April.

iancarroll 12y ago

This is actually solid grounds for removal in all trust stores, honestly. They did numerous things wrong (from what I am reading here): - The CA must have had some warning that it wasn't being loaded onto a HSM - It was never verified the CSR/key was generated on a HSM (!!!) - The auditors did not oversee the key being generated (this is typical for roots, although not for intermediaries) - If this subordinate was in operation for >1yr, how was this not caught in an audit? and you can't load a certificate off of a HSM, so I'd argue the CA is entirely at fault here.

yuhong 12y ago
The fourth point is not true, I looked at the intermediate myself. In fact the test intermediate is only days old at the time of the writing and last less than a month before it expires.

click170 12y ago

Is anyone else frustrated after trying to load this page on a mobile device? I zoom in to read the text and when I try to slide the screen over, it interprets that as me wanting to go to the next page. No, I wanted to read the text on THIS page.

qeorge 12y ago

Honest question: as a United States internet user, is there any practical reason I need to have a root certificate from the Chinese national Internet authority installed? Corollary, is there a short list of CAs that folks around here trust more than average? Is there any value in such a whitelist, or are all CAs so rotten it doesn't much matter?

kjs3 12y ago
If you regularly visit Chinese sites that use HTTPS.
- lucaspiller 12y ago
  ...that use this CA. I regularly use Alibaba, but their certificates are signed by "VeriSign Class 3 Secure Server CA - G3".
kijin 12y ago
There was a bit of controversy a few years ago when Mozilla added CNNIC to Firefox's list of trusted CAs. I removed CNNIC from my browser shortly afterwards. No problem so far. I don't think you'll have much problem even if you only trusted a few U.S. megacorporations, such as Verisign, Comodo, GeoTrust, GoDaddy, etc. They're no more trustworthy than the rest, but at least they're much more widely used than some government agency of a country you have nothing to do with.

colinbartlett 12y ago

What can a site administrator do today to combat these kinds of flaws? Is there some certificate pinning technology (I don't fully understand what that is) I can use on my own sites now to push in the right direction? I try to be an early adopter of such practices such as using SSL all the time on all my sites.