Understanding Man‑in‑the‑Middle (MITM) Attacks and How HTTPS & HSTS Defend Against Them

In a previous article the author briefly introduced how HTTPS works and mentioned Man‑in‑the‑Middle (MITM) attacks; this article expands on what MITM attacks are.

What Is a Man‑in‑the‑Middle Attack

According to Wikipedia, a MITM attack occurs when an attacker establishes separate connections with both ends of a communication, intercepts and possibly alters the data, making the two parties believe they are talking directly while the attacker controls the entire session.

In simple terms, the attacker acts as a messenger who can read, insert, delete, or modify any part of the conversation without either side noticing.

MITM attacks are not limited to HTTPS; on unsecured Wi‑Fi networks an attacker can easily insert themselves between the client and server and tamper with the traffic.

A Plain‑Language Example

Tom wants to exchange secret information with Jerry but doesn’t want to visit Jerry’s house, so he asks a mail carrier to deliver a letter requesting a locked box with two keys and one of the keys.

The mail carrier reads Tom’s letter, understands the request, repackages it, and gives it to Jerry.

Jerry, believing the letter is unchanged, sends Tom a locked box and one key.

The mail carrier swaps Jerry’s box for his own, adds his own key, and returns the box to Tom.

Tom puts his secret inside the box, leaves the key, and hands the box back to the mail carrier.

The mail carrier opens the box with his other key, reads the secret, replaces the contents, and gives the box to Jerry.

Jerry, unaware of the swap, thinks the box contains Tom’s original message and replies by putting a response in the box and sending it back via the mail carrier.

The mail carrier swaps the box once more and returns it to Tom.

In HTTPS terminology, Tom is the client, Jerry is the server, and the mail carrier represents any intermediary (proxy, router, reverse proxy, etc.). The two keys correspond to the public and private keys. Because neither side verifies the other’s identity, the intermediary can read, modify, or drop the communication.

How HTTPS Defends Against MITM Attacks

To prevent MITM attacks, the parties must ensure that the information they receive truly originates from the claimed entity and has not been altered. Digital signatures provide this guarantee: the sender hashes the message, encrypts the hash with their private key, and attaches the signature. The receiver hashes the received message, decrypts the signature with the sender’s public key, and compares the two hashes.

If an attacker replaces the public key during the handshake, they could still impersonate the other party. To solve this, a trusted third‑party— a Certificate Authority (CA)—issues digital certificates that bind a public key to an identity.

A digital certificate contains the applicant’s public key, name, email, validity period, etc. The CA validates the applicant’s identity and signs the certificate with its own private key. Recipients verify the certificate by decrypting the signature with the CA’s public key and checking that the certificate’s hash matches.

The trust chain works as follows:

Public‑key encryption guarantees confidentiality; only the holder of the matching private key can decrypt.

Certificates validate that a public key truly belongs to the claimed entity.

Higher‑level CAs sign lower‑level certificates, forming a chain up to a root CA.

The root CA is self‑signed; its private key must remain secret to protect the entire chain.

Root certificates are pre‑installed in operating systems and browsers, not distributed over the network, to avoid tampering.

Once a device trusts a root certificate, the entire trust chain becomes secure.

SSLTrip and HSTS

Originally HTTP was plaintext. Modern sites use HTTPS, but many users are unaware of the difference. When a user types www.example.com without the scheme, the server typically redirects (301 or 302) to https://www.example.com . An attacker performing an SSLTrip can block the HTTPS upgrade, keeping the connection on HTTP while establishing a legitimate HTTPS connection to the server, thus intercepting the traffic.

To mitigate this, the IETF introduced HTTP Strict Transport Security (HSTS). HSTS forces browsers to use HTTPS for a site after the first successful HTTPS connection, even if the user types an HTTP URL. The server sends the header:

Strict-Transport-Security: max-age=31536000; includeSubDomains

This tells the browser that for the next year all requests to the domain (and its subdomains) must be made over HTTPS, and that invalid certificates will block access.

If a site does not enable HSTS, users can ignore certificate warnings; with HSTS enabled, browsers will refuse the connection regardless of user choice. However, HSTS only works after the browser has made at least one HTTPS connection. To protect against a persistent MITM that blocks the initial HTTPS handshake, browsers can ship a built‑in list of HSTS‑preloaded sites, allowing them to enforce HTTPS without a prior connection.

Below are illustrative images of the trust chain and HSTS behavior:

In summary, MITM attacks exploit the lack of authentication in a communication channel; HTTPS, digital certificates, and the HSTS policy together provide layered defenses that verify identities, ensure integrity, and enforce secure connections.