Skip to main content
2 of 3
change Eve to M and other polish
fgrieu
  • 1.3k
  • 8
  • 21

Ongoing effort to detect MitM attack on TLS?

Client B connects to server A using TLS. B knows A by it's FQDN (e.g. www.alice.tld), and by a root certificate for a CA that issued a certificate to A for this FQDN. Say B uses HTTPS and a standard web browser, and the certificate A holds comes with a chain of certificates to a CA which is in B's browser's whitelist.

State actor M is able to coerce B's ISP to use routers M supplies (or equivalently, route B's traffic thru a router under control of M). M also is able to get certificates that B's browser will trust for any FQDN, because M has foot in one of the myriad of CAs with this ability.

Correct me if I'm wrong, but AFAIK there's nothing built into TLS or HTTPS to stop M from having their router perform a MitM attack, where the router holds a rogue certificate for A's FQDN, uses it to impersonates A w.r.t. B, and connects to A as B would (here, unauthenticated). In theory, no public point-to-point protocol can be effective against such MitM attack.

However, in practice, that could be detected

  1. Some link from A to B with trusted integrity will do: A can publish the certificates it uses (or just their hashes/fingerprint), and B can check if the certificate it uses as being A's is in this list.
  2. Some public service could try to do just that instead of A, collecting certificate(s) A uses thru a variety of links hopefully out of the influence of M, and republishing it as tweets, radio broadcasts, printed handouts, or other hard-to-censor means.
  3. It's enough to pass that same info on top of the TLS link using a protocol against which M has not yet implemented countermeasures. For a start, a new experimental HTTP(S) header where A sends the hash of the certificate it currently uses would do.

Question: is there some ongoing effort to detect such MitM attack on TLS? What method(s) does it use?

fgrieu
  • 1.3k
  • 8
  • 21