It seems like everyone was biased against TrustCor because they didn't want their privacy violated.
A separate company used an SDK which later was classified as malware and now TrustCor is no longer trusted. That is pretty unfair.
A separate company used an SDK which later was classified as malware and now TrustCor is no longer trusted. That is pretty unfair.
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.
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.
It's a choose only 1 sort of deal.
circumstantial evidence, but nothing that was definitive
>The CA had no substantial public certificate issuing program
So just because they don't have enough customers they should be removed? This just promotes centralization of trust.
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.
CAs should be assumed guilty until proven otherwise.
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.
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.
TrustCor doesn't actually dispute that MsgSafe is the same company as them. For example, here is a press release where they proudly announce they own MsgSafe: https://www.prnewswire.com/news-releases/trustcor-evolves-em...
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.)
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.
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.