24 ms·

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

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.

lolinder 4y ago
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.
- mewse 4y ago
  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?
  - woodruffw 4y ago
    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.
  - lolinder 4y ago
    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.
  - estel 4y ago
    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.
    - lolinder 4y ago
      Yes, which could explain the lack of obfuscation but would not explain the source code modifications that hard code a MsgSafe certificate and URLs.

lolinder 4y ago

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.

mewse 4y ago
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?
- woodruffw 4y ago
  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.
- lolinder 4y ago
  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.
- estel 4y ago
  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.
  - lolinder 4y ago
    Yes, which could explain the lack of obfuscation but would not explain the source code modifications that hard code a MsgSafe certificate and URLs.