Certificate Pinning & MITM Defense

Attack & Defense

Connection attempt rate 1 / 2.5s

Live Handshake

Idle — waiting for next connection attempt…

pinned SPKI–

presented SPKI–

Session Stats

Attempts

Connected

MITM blocked

MITM succeeded

How it works

Certificate (SPKI) pinning hard-codes, inside the app itself, the SHA-256 hash of the server's expected public key — not the whole certificate. On every TLS handshake the app checks the key the server actually presented against that pin set, on top of normal CA-chain validation:

pins = { H(SPKI_expected), H(SPKI_backup) }
connect ⇔ H(SPKI_presented) ∈ pins   ∧   CA chain valid

Without pinning, any certificate signed by a trusted root is accepted — including one minted by a compromised or user-installed CA, which is exactly how a MITM proxy intercepts traffic. With pinning enabled, the attacker's certificate has a different public key, so H(SPKI_presented) never matches the pin set and the connection is torn down before any data is exchanged.

The catch is pinning's failure mode is self-inflicted outage, not just security: rotate the real server certificate without a staged backup pin, and the legitimate server's new key also fails the same check. This is why real deployments always ship at least one backup pin alongside the primary — try the Rotate Server Certificate button with and without Backup Pin Staged to see both outcomes.

Certificate Pinning — toggles whether the app checks presented keys against its pin set at all.
MITM Attacker — inserts a proxy between app and server that swaps in its own certificate, using a different key pair each time.
Backup Pin Staged — pre-registers the server's next key so a legitimate rotation doesn't lock users out.
Rotate Server Certificate — the server generates a fresh key pair, simulating a real cert renewal event.

Mobile app Legitimate server MITM attacker

⚠ Couldn't load the 3D engineThree.js failed to load from the CDN. Check your connection and reload.