Ongoing effort to detect MitM attack on TLS?

Question

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 impersonate 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?

Answer 1

Certificate transparency is a system that indexes all certificates. Domain owners can watch the certificate transparency logs to see if any certificate has been issued that they did not request. Browsers may check the certificate log, to make sure that every certificate they encounter is added to the log.

So M can create a certificate and:

• not add it to the log. B's browser can detect that the certificate has not been added, and is thus likely a fraudulent certificate.
• add it to the log. A can detect that a unauthorized certificate has been issued.

Answer 2

Certificate pinning (or public key pinning) is used by many browsers for at least some sites, and by some non-browser client software. The idea is that the client (browser or otherwise) is programmed to check the certificate it receives against known properties of the legitimate certificate. For example, the client might verify that the certificate uses one of a few public keys (the current one when the client was built, and future/back-up in case rotation is needed), or that the certificate is issued by a particular CA, or similar. In extreme cases you can pin the entire leaf certificate, but that means any update or rotation will require a client update to remove the old cert and add a new future cert.

Cert (or public key) pinning is most common when the software and the server are provided by the same developer. Google pins all of their properties in Chrome. Microsoft might do the same in Edge - not sure - but they definitely do it for some other software (registration servers, I think also the default update servers). I think Firefox might do so for Mozilla properties. You'll also see it with things like apps (Twitter, for example, might use pinning in their mobile apps, though I don't know if they do). At least one fraudulent Google certificate has been detected via this mechanism.

There was an attempt to standardize a way for sites to provide their own pins to browsers, too. It was called HTTP Public Key Pinning, or HPKP, and allowed sites to specify properties of their certificates (and a mandatory backup), with an expiration, much the same way HTTP Strict Transport Security (HSTS) works. Like HSTS (and also similar to SSH), it was trust-on-first-use; any valid HTTPS response could include the header, and as long as it matched the current cert, it would be trusted. Unlike HSTS, HPKP was never widely adopted, and is now deprecated. Some browsers might be configurable to enable it - my copy of Firefox still has "security.cert_pinning.hpkp.enabled" in about:config - but it's disabled by default.

One of the features of HPKP was the ability to set a report URL. Similar to Content Security Policy (CSP) - although it seems CSP has also deprecated this - HPKP allowed specifying that the client should send reports of invalid certificates it encountered for the site. The idea was, collect information as widely as possible about potential attacks going on. If the client had a clear connection to a third-party site, they could report the fraudulent certificate there (connections to the site with the fraudulent cert being intercepted already, the attacker presumably wouldn't allow the report to pass).

There's also the EFF SSL Observatory, which monitors the certs used online. In theory this could detect unexpected certificate changes, or situations where different people see different certs.

---

To address your ideas #1 and #3, the problem there is that, if the connection to the server is compromised, the attacker can just modify the content that the client receives. You read a list of hashes, or check a header, and see that it matches the cert you just received... because a simple string substitution swapped out the legit cert's hash for the fraudulent one. This kind of transformation is not new; things like SSLStrip use it to re-write URLs. It would be pretty simple to make this work for the common hash algorithms and encoding formats.

To prevent that kind of attack, you need either a system that remembers the old value (this is what HPKP was aiming to do, with its duration settings), or a third party (which is hopefully reachable over a secure connection!) such as you see with Certificate Transparency (as covered in another answer).