3 ms·

As far as I understand it, there are basically five organizations involved: 1. TrustCor operates "TrustCor CA" and "MsgSafe". TrustCor claims these are complet

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.

jrpelkonen 4y ago
Small correction to your item 4: In order to MITM https, you need access to root key. Certificates are public.
- 4str0n0mer 4y ago
  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.
  - tialaramex 4y ago
    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.
    - 4str0n0mer 4y ago
      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.
deleted 4y ago
[deleted]

jrpelkonen 4y ago

Small correction to your item 4: In order to MITM https, you need access to root key. Certificates are public.

4str0n0mer 4y ago
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.
- tialaramex 4y ago
  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.
  - 4str0n0mer 4y ago
    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.

deleted 4y ago

[deleted]