Hacker News Reader

Comment by advisedwang | Hacker News Reader

> The conclusion on the mailing list was roughly: look, we're not here to find you guilty in a court of law, we're here to decide whether we trust you, and after all that we definitely don't.

They weren't untrusted just because of the behaviour. A really important dimension is that TrustCor certificates were only being used for very limited purpose. The actual decision is a a cost vs benefit analysis from the point of view of internet users. Because there's so little benefit, it takes only very little untrustworthiness before the best course of action is to distrust.

View on HN

The browsers constantly wield this argument, but I don't like it. It necessarily leads to centralisation of CAs and going back to old days of VeriSign.

I don't think we should be going towards LE/ISRG being the only organisation allowed to issue certificates for "cost vs benefits analysis" of allowing other entities to issue certs. It would be a single point of failure and a massive target for various non-state and state actors.

I agree in general, but in this case it was pretty clear-cut: TrustCor was a CA primarily to serve a single product, MsgSafe.io. This is the same product that was found to have bundled the only known unobfuscated Measurement Systems malware and was also found to be claiming E2E encryption when very rudimentary tests showed they couldn't possibly be encrypting the email.

Since their only known benefit was issuing certificates in support of a quite-possibly-shady email system, I'm comfortable with saying that the cost-benefit analysis comes down firmly against TrustCor.

The "the only product known to have embedded unobfuscated Measurement Systems malware" phrase got used a whole lot, in the OP and in comments here as well as in the original email thread, but nobody really explained why that factor was important (or maybe I just missed it?)

Can somebody explain the significance of the malware being unobfuscated, and why that's apparently more concerning than if it had been obfuscated?

The presence of the unobfuscated malware suggests that it originates with them, instead of it being an unwitting component of their application.

In other words: it suggests that the CA and the malware creator are one and the same, which was then further substantiated by their shared executives, addresses, etc.

All known copies of the malware were obfuscated, meaning the variable and function names were renamed to nonsense. The version included in MsgSafe did not have garbled variables and it had source code modifications to hard code a MsgSafe certificate and servers.

This suggests that the relationship between MsgSafe and Measurement Systems was not a typical "oops, we added a library that turned out to be malware" relationship. Instead, they seem to have had access to the raw source code, rather than the packaged binaries, which in conjunction with other evidence indicates a close degree of collaboration between the malware developers and MsgSafe. It's not a smoking gun, but it's enough to warrant distrust.

The suggestion might be that Trustcor received an internal build of the SDK because of their close links to the company. Perhaps the developer who worked on the mobile app also worked for the company behind the SDK?

Rachel’s suggestion in the thread is that the other examples of this SDK that have been observed obfuscated are much more recent, and that perhaps obfuscation was something the company has started doing more recently.

Yes, which could explain the lack of obfuscation but would not explain the source code modifications that hard code a MsgSafe certificate and URLs.

Reply on news.ycombinator.com