On Tue, Dec 11, 2018 at 05:37:41AM +0000, Xiaoyin Liu via dev-security-policy wrote: > It’s clear that the private key for *.alipcsec.com is embedded in the > executable,
There are ways of implementing SSL such that the private key doesn't *have* to be stored locally. They all require the TLS termination point to be able to communicate with the service that *does* hold the private key, so a good way to test that the key is stored locally is to remove external connectivity and then try to establish a TLS connection. If you still can, the key has to be *somewhere*. > packed by VMProtect, and the process has anti-debugging protection. I > tried plenty of methods to extract the private key, but didn’t succeed. I > reported this to Alibaba SRC anyway. They replied that they ignore this > issue unless I can successfully extract the key. That sounds like it might be an admission that the binary *is* in the executable, and they're just hoping you won't be able to get it. > So is this a certificate misuse issue, even if the private key is > obfuscated? If so, do I have to extract the private key first before the > CA can revoke the cert? Sadly, some CAs do indeed require you to *actually* produce the private key in order for them to consider the key compromised. Given that people can pull apart Nation-State grade malware I think "we don't *know* that anyone's found it yet" is lamentably short-sighted, but absent an explicit rule that a key is considered compromised if it can be shown that it *must* be in a local executable, some CAs will continue to stick to their current standards. You can see how a similar situation played out in the past, in https://groups.google.com/d/msg/mozilla.dev.security.policy/pk039T_wPrI/tGnFDFTnCQAJ However, I don't know what GlobalSign's policy is regarding revocation proof. Rather than just talking to Alibaba, it would be worth contacting GlobalSign's problem reporting address (which is listed in the problem reporting list in the CCADB, at https://ccadb-public.secure.force.com/mozilla/AllProblemReportingMechanismsReport) and putting the situation to them. - Matt _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
