There was no intention to MITM here. MCS's goal was to become a certificate authority, and it's common practice for a new CA to get their CA cert signed by an existing one. Let's Encrypt is planning on doing exactly this, for instance.
What went horribly wrong is that nobody knew what they were doing, CNNIC didn't realize they had an obligation to bring in auditors to both CNNIC and MCS to make sure that people knew what they were doing, and MCS unintentionally placed the cert on a device that happens to do real-time SSL MITM.
I believe CNNIC's claim is about the "test" certificate that was issued to MCS. (The fact that they issued a test certificate off of a publicly-trusted one is another sign they didn't know what they were doing.)
There's a long thread on mozilla.dev.security.policy with replies by CNNIC and MCS that explains the story. (The CNNIC rep's English is pretty good, MCS's is good enough to get a sense of things.) https://groups.google.com/forum/#!topic/mozilla.dev.security...
> MCS unintentionally placed the cert on a device that happens to do real-time SSL MITM
That's right up there with "unintentionally loaded a gun, drove to the bank, held it up at gunpoint, and left with bags full of cash", and about as believable. If it really was unintentional, then it's still a level of incompetence sufficiently indistinguishable from malice that it should be treated as malice.
Maintaining certificate security is the primary job of a certificate authority. A certificiate authority that utterly failing to do so should be removed from the trusted CA list, as has occurred here.
> That's right up there with "unintentionally loaded a gun, drove to the bank, held it up at gunpoint, and left with bags full of cash", and about as believable.
While I'd like it if it that were the case... did you see the PDFs that I linked elsewhere in this discussion thread, that CNNIC originally posted to mozilla.dev.security.policy?
I can see the following series of incompetences as entirely too plausible:
- MCS happens to have some multi-function Palo Alto devices, because they're reasonable devices to have for a network operator.
- Palo Alto ships real-time SSL MITM capabilities (i.e., loaded guns) in their products, because lots of customers want them for use with internal CAs.
- Palo Alto is also a FIPS-compliant hardware crypto device, because thanks FIPS.
- MCS and CNNIC both vaguely know that intermediate certificates should only be kept on FIPS-compliant hardware crypto devices. They don't know why, they just know it's what people do.
- MCS looks around, sees the Palo Alto device, decides it's the right sort of device to use, and clicks the "Generate a CSR" button and sends it to CNNIC.
In any case I certainly agree that this deserves CNNIC removal, even if everything CNNIC and MCS has said is true (they're both admitting to gross negligence that failed at the most basic tasks of a CA, even if there was no malice in a strict sense). And also deserves MCS or any suspiciously similar organization being blacklisted by all the other CAs if they come asking for an intermediate.
Like, if it weren't for the hardware crypto requirement, it sorta sounds like MCS would have happily run `openssl req` on some developer's machine, and CNNIC would have happily signed it with their globally-trusted CA cert. Which would not have set off Google's tripwires, but would also have been completely unacceptable.
A CA hitting the "generate CSR" button and not knowing what it does should not be a CA, full stop. 100% of the job of a CA is understanding private keys, public keys, CSRs, and the security policies surrounding them.
And I would agree: if a CA is delegating trust to another wannabe CA who is so ignorant, that CA is also negligent and should also have its cert yanked.
The explanation that the delegation was just so that MCS could MITM their own computers is also strange; as Google notes, the normal behavior for such a proxy is to set up your own signing infrastructure and push out your own CA to all machines under your control. Delegating the ability to generate certs for any domain and saying "but dont use it!" is utterly irresponsible.
Theres also a degree of deserved paranoia here; this is CA based in a country that is well known to target Google (as they are the one major search provider not cooperating with the Chinese government), who just happens to accidentally delegate CA rights to an org who accidentally generates certs for Google. Alarm bells are ringing.
What went horribly wrong is that nobody knew what they were doing, CNNIC didn't realize they had an obligation to bring in auditors to both CNNIC and MCS to make sure that people knew what they were doing, and MCS unintentionally placed the cert on a device that happens to do real-time SSL MITM.
I believe CNNIC's claim is about the "test" certificate that was issued to MCS. (The fact that they issued a test certificate off of a publicly-trusted one is another sign they didn't know what they were doing.)
There's a long thread on mozilla.dev.security.policy with replies by CNNIC and MCS that explains the story. (The CNNIC rep's English is pretty good, MCS's is good enough to get a sense of things.) https://groups.google.com/forum/#!topic/mozilla.dev.security...