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?


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.
  • 1
    I came across crt.sh which seems sort of usable for that "certificate transparency".
    – fgrieu
    Apr 26 at 12:19
  • 1
    What if M only adds it to the log when the log is in transit to B's browser? So B sees it in the log, but A doesn't. Apr 27 at 0:32
  • @Brian McCutchon: If M knows what B does and can alter any avenue of communication to B and does so properly, then M can't be caught. That's why in the question's 1 and 2 I posit a channel with integrity, and in 3 a channel that is covert w.r.t. M.
    – fgrieu
    Apr 27 at 5:47
  • 2
    @BrianMcCutchon The browser doesn't download/query the log itself (that would put a ginormous load on the log servers). Instead it just checks if the certificate has an SCT (which is basically a signed statement by the log operator that the certificate has been added to the log). SCT auditing is then required to ensure the log operator didn't issue a fake SCT (currently I think only chrome does SCT auditing for some clients, but even that confers herd immunity against at least mass MiTMs).
    – nobody
    Apr 27 at 11:58
  • 1
    And if the MITM guy blocks access to the logs outright?
    – Joshua
    Apr 27 at 18:07

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).

  • 3
    Is certificate pinning really "used by many browsers"? HPKP has been removed from most browsers. Is there another mechanism to pin certificates in the browser?
    – Sjoerd
    Apr 26 at 11:17
  • 4
    @Sjoerd Dynamic HPKP has been removed, but static HPKP remains for many major sites (like Google) whose public key fingerprints are hardcoded in the browser.
    – forest
    Apr 27 at 3:51
  • 3
    @Sjoerd As Forest says, static ("preloaded") pinning is used quite a lot, see for example the current set of preloads in Firefox. It's just that with the demise of TOFU dynamic pinning through HTTP headers, this mechanism is pretty much only for the big players, with no way to leverage it for all the small sites out there. (That was actually the reason it was dropped, because many sites tended to shoot themselves in their feet trying to deploy HPKP and not getting it right.)
    – TooTea
    Apr 27 at 8:26
  • 1
    @TooTea It's really a shame that it was removed, since I always used it (and used it correctly). Browsers merely supporting it hurts no one.
    – forest
    Apr 27 at 9:12
  • 1
    Yeah, one of the main reasons given for deprecating HPKP was that anybody who managed to take over a website temporarily could use HPKP with a long duration on anybody who visited. If they installed their own cert (obtained from any CA that uses proof of server control, such as checking for a key in a specific location), they can then remove that cert and any affected user's browser will refuse to connect. If the malicious cert isn't removed, or even isn't installed, the admin still can't rotate the cert which means the attacker perpetually has the private key. There was concern about ransoms.
    – CBHacking
    Apr 29 at 8:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.