How HTTPS Defends Against Man‑in‑the‑Middle Attacks: A Deep Dive

What HTTPS protects against

HTTPS is designed to prevent Man‑in‑the‑Middle (MITM) attacks, where an attacker intercepts, reads, or modifies traffic between a client and a server without either party noticing.

Common MITM techniques

Domain‑name poisoning: the attacker hijacks DNS resolution and returns a malicious IP address.

ARP spoofing: the attacker tricks a local router into sending traffic to the attacker’s MAC address.

Why HTTPS is the only effective defense

The SSL/TLS source code contains a comment that highlights certificate verification as the sole defense against MITM:

/* cert is OK. This is the client side of an SSL connection.
 * Now check the name field in the cert against the desired hostname.
 * NB: This is our only defense against Man‑In‑The‑Middle (MITM) attacks! */

During the handshake the server presents a certificate, the client validates its signature chain and hostname, and only then proceeds to encrypt data.

HTTPS handshake process (captured with Wireshark)

Client Hello : the client sends TLS version (e.g., 1.2), a random nonce, a session ID (0 for first connection), and a list of supported cipher suites.

Server Hello : the server replies with its chosen TLS version, a random nonce, a session ID, and the selected cipher suite (e.g., TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256).

Certificate : the server sends its certificate chain (leaf, intermediate, root). The chain can be inspected in Wireshark; for example, the tmall.com certificate chain includes *.tmall.com, GlobalSign Org., and GlobalSign Root.

Server Key Exchange : the server provides its ECDHE parameters.

Certificate Verify : the server proves possession of the private key.

Client Key Exchange : the client sends its ECDHE public key (65 bytes) to the server.

Change Cipher Spec (both sides): each side signals that subsequent records will be encrypted with the newly derived keys.

Encrypted Application Data : HTTP payload is transmitted over AES‑128‑GCM, protected by the shared secret.

Wireshark timestamps show that the whole handshake takes roughly 0.3 seconds (e.g., from 4.99 s to 5.30 s).

RSA key details from the certificate

The leaf certificate’s public key is a 2048‑bit RSA key represented as a 270‑byte hexadecimal string:

String publicKey = "3082010a0282010100c70e6c3f23937fcc70a59d20c30e533f7ec04ec29849ca47d523ef03348574c8a3022e465c0b7dc9889d4f8bf0f89c6c8c5535dbbff2b3eafbe356e74a46d91322ca36d59bc1a8e3964393f20cbce6f9e6e899c86348787f5736691a191d5ad1d47dc29cd47fe18012ae7aea88ea57d8ca0a0a3a1249a262197a0d24f737ebb473927b05239b12b5ceeb29dfa41402b901a5d4a69c436488def87efee3f51ee5fedca3a8e46631d94c25e918b9895909aee99d1c6d370f4a1e352028e2afd4218b01c445ad6e2b63ab926b610a4d20ed73ba7ccefe16b5db9f80f0d68b6cd908794a4f7865da92bcbe35f9b3c4f927804eff9652e60220e10773e95d2bbdb2f10203010001";

The key consists of the modulus N = p × q and the public exponent e = 65537. Decrypting a signature involves modular exponentiation:

String decode = new BigInteger(signature, 16)
    .modPow(BigInteger.valueOf(e), new BigInteger(N))
    .toString();
System.out.println(decode);

Verifying the certificate signature

The signature is a 256‑byte value computed as sign = (hash)^{d} mod N where d is the issuer’s private key. To verify, compute the SHA‑256 hash of the DER‑encoded tbsCertificate and compare it with the hash extracted from the signature. The hash matches, confirming the certificate has not been tampered with.

Key exchange details

The chosen cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 splits into three parts:

Key exchange: ECDHE_RSA (ECDH for key agreement, RSA for authentication).

Bulk encryption: AES_128_GCM.

Integrity: SHA256.

ECDHE provides forward secrecy with short keys (≈224 bits) while RSA authenticates the server.

Cost of using HTTPS

Handshake latency (~0.3 s).

Additional CPU for encryption/decryption.

Encrypted payload is larger, consuming more bandwidth.

Bypassing HTTPS (for educational purposes)

Tools like sslstrip perform ARP spoofing to downgrade an HTTPS connection to HTTP, creating a MITM scenario. Detect such attacks by checking for the missing lock icon in the browser address bar.

Creating a self‑signed certificate

A simple OpenSSL command generates a self‑signed certificate valid for 365 days:

openssl req -x509 -nodes -sha256 -days 365 -newkey rsa:2048 -keyout test.com.key -out test.com.crt

After generation, import the certificate into the browser’s trust store to avoid NET::ERR_CERT_AUTHORITY_INVALID errors.