As far as I understand it, there are basically five organizations involved:
1. TrustCor operates "TrustCor CA" and "MsgSafe". TrustCor claims these are completely separate lines of business, but does not dispute that it owns and controls both of them.
2. MsgSafe incorporated a spyware SDK from Measurement Systems into their Android app. TrustCor claims this was done by a rogue contractor (and thus TrustCor had no control over it), and they also claim it wasn't a security breach (implying TrustCor allowed the contractor to do it). Also, MsgSafe claims to offer end-to-end encryption while demonstrably not offering end-to-end encryption.
3. Measurement Systems produced a tracking SDK that is now considered spyware. It has historically shared many high-level employees with TrustCor, including (allegedly) having the same CFO and CEO.
4. Vostrom aka Packet Forensics sells spy equipment that claims to be able to break HTTPS, like you'd be able to do if you had access to a root certificate. They have nebulous ties to both TrustCor and Measurement Systems.
5. TrustCor CA is no longer trusted because of the above, and because its VP answered questions about it by saying her lawyer advised her not to comment.
Another small correction: In order to MITM https, you need access to either a trusted root certificate and key, or a key & certificate with the CA bit set, signed by a valid root CA.
Assuming you haven't somehow stolen the real site owner's private key, you would need to produce a certificate for that DNS name, signed with a key you do have.
Which is something you could in principle do if you are a trusted root CA. But, this creates a smoking gun. The bogus certificate is a public document, you're always giving it to the client, and for Chrome, Safari, Chromium Edge you are also obliged to publicly log the certificate, where everybody can see it forever, in order to have an SCT (proof of logging) which those browser insist on seeing.
Modern rules require a root CA to disclose any intermediate CAs which are created, even if not currently in use (e.g. because still being tested) and which could issue trusted certificates unless the certificate for the intermediate is technically constrained (which is complicated, but a general purpose CA is not technically constrained for the purpose of this definition)
In practice, most outfits offering "MITM" type capabilities are for corporate environments, education, that sort of thing, where you can say "All employers/ students/ whatever shall trust our our private CA FOO" and then you can MITM using the trusted FOO CA. So this doesn't interact with the Web PKI overseen by m.d.s.policy at all. If you don't want to get MITM'd don't trust some sketchy private CA.
Maybe a sufficiently crafty vendor of MITM equipment could prevent MITM site certificates that are signed by evil intermediate CAs from appearing in CT logs by filtering access to those CT logs. But it is a risky proposition for the vendor, as you've said.
A company with such an important role on the internet should be extremely transparent, there’s no benefit to the end-users of giving such a company such amount of privacy.
Since there was substantial evidence that these were one and the same company. The CA had no substantial public certificate issuing program regardless so kicking it out was an easy decision either way (and begs the question what exactly it is they were doing to justify the multi million dollar operating costs of a root CA).
It really doesn’t matter if it was circumstantial or not. When presented with such evidence, the TrustCor rep was extremely evasive. This isn’t a court of law; if a Root CA can’t be up-front about explaining evidence that calls their trust into question, then they cannot be trusted and deserve to have their certificates yanked.
Yeah I personally feel for the rep, they were indeed under attack. But there is no going around it, a company that advertised a product as being e2e encrypted when it really was not, having multiple levels of ties with the CA was enough to deem the CA as unfit.
I agree with this conclusion because the CA ecosystem is a fragile one if not governed strictly, since the risks are of the highest concern to the general use of the Internet.
> circumstantial evidence, but nothing that was definitive
That's not how things work. The role of a Certificate Authority is to act as a trusted third party. If that third party is unable or unwilling to demonstrate that they are trustworthy then naturally they can't be expected to assume that role.
Looks to me like Trustcor’s subsidiary company MsgSafe made an app containing spyware. In addition, that spyware funneled data to a hardcoded url on a MsgSafe server which the Trustcor rep openly admits was only protected by a self-signed cert of unknown origin and was forwarded to unknown destinations as raw tcp packets.
There is a lot of doubletalk in the thread that is supposed to somehow lead us to believe that TrustCor CA and MsgSafe are totally separate companies, despite lots of circumstantial evidence that they aren’t.
It also happens to appear that MsgSafe and the company that actually created the malware (Measurement Systems) might be closely related and/or the same, owing to a lot of the same names on corporate documents (many of which names are shared with Trustcor and/or Trustcor CA), plus the extremely suspicious fact that the malware in question was only ever distributed elsewhere in obfuscated form, yet somehow MsgSafe seems to have an unobfuscated copy built into their app.
It’s also extremely odd that despite all the protestations about Trustcor CA and MsgSafe being completely unrelated, the Trustcor CA director of business operations has intimate knowledge of the source control, server configurations, and VM snapshots of the server that the traffic was being proxied through at MagSafe.
> There is a lot of doubletalk in the thread that is supposed to somehow lead us to believe that TrustCor CA and MsgSafe are totally separate companies, despite lots of circumstantial evidence that they aren’t.
Instead, what they claim is that these two parts of the business are operated separately. As in, MsgSafe doesn't run on the same servers as the CA. So if a "rogue contractor" adds malware to MsgSafe and it goes undetected for several years, that shouldn't reflect badly on the CA side of the business at all.
(TrustCor was so evasive about this that they seem to have misled most of the people in this thread, though.)
> what they claim is that these two business are operated separately
except that the person doing all this claiming happens to be director of operations for both.
I concede that it isn’t impossible that they have a strong firewall between these two companies. But all the obfuscation, defensiveness, and easily refuted claims don’t really make anyone willing to swallow that story.
Given that, according to TrustCor's own statements, MsgSafe relies heavily on certificates issued by TrustCor, I don't think there's all that much separation. (There might be, like, a network firewall in between the two server fleets, but even that is doubtful.)
Yeah, reading through this whole saga, one of the things I wondered was whether MsgSafe might actually have the ability to get any certificate it wants from Trustcor CA through this special relationship. If it’s got that kind of permission, all the corporate governance separation in the world isn’t going to matter.
I think the concern is less about MsgSafe getting any certs it wants and more about how shoddy development practices (letting the third party malware SDK be incuded) and business ethics (false E2EE advertising and typo squatting) at MsgSafe reflect on TrustCor's ability to operate a CA given the shared management.
The other large concern is the large number of links between TrustCor and Packet Forensics, Measurement Systems and Volstrom Holdings. Specifically the history of shared ownership, corporate officers, and the inclusion of a the only known non-obfuscated copy of a Measurement Systems malware SDK by a "rogue contractor" for TrustCor.
As an aside, I though it was interesting that Rachel made a point of placing the blame on a contractor and then later admitted that they pay all their "employees" via 1099s.
A separate company used an SDK which later was classified as malware and now TrustCor is no longer trusted. That is pretty unfair.