Understanding HTTP, HTTPS, and How They Prevent Man‑in‑the‑Middle Attacks

1. HTTP Protocol

Before discussing HTTPS, we briefly review the concept of HTTP.

1.1 Introduction to HTTP

HTTP is a text‑based transfer protocol that operates at the Application Layer of the OSI model.

Communication follows a request‑response pattern. The original RFC 2616 has been split into six separate specifications (RFC 7230‑7235). A typical request looks like:

POST http://www.baidu.com HTTP/1.1
Host: www.baidu.com
Connection: keep-alive
Content-Length: 7
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

wd=HTTP

And a typical response:

HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html;charset=utf-8
Date: Thu, 14 Feb 2019 07:23:49 GMT
Transfer-Encoding: chunked
...

1.2 Man‑in‑the‑Middle (MITM) Attack on HTTP

Because HTTP transmits data in clear text, an attacker can intercept and modify both requests and responses. The article illustrates this with a simple example where a user’s post "I love JAVA" is altered to "I love PHP" by a MITM.

1.3 Preventing MITM Attacks

One might think of encrypting the payload with symmetric encryption (e.g., AES). However, if the key exchange itself is performed in clear text, the attacker can capture the symmetric key and decrypt subsequent traffic.

To protect the key, asymmetric encryption (RSA) is introduced: the server generates a public‑private key pair, sends the public key to the client, the client encrypts the generated AES key with the server’s public key, and the server decrypts it with its private key. The encrypted AES key (AES_KEY_SECRET) is then used for symmetric encryption of the actual data.

Even this approach can be subverted if the attacker performs a rogue key exchange, presenting a forged public key to the client and thus obtaining the AES key.

2. HTTPS Protocol

2.1 Introduction to HTTPS

HTTPS is essentially SSL+HTTP (nowadays SSL is largely replaced by TLS). SSL/TLS provides a handshake to exchange keys securely, after which symmetric encryption secures the data transfer.

The handshake involves the server presenting an SSL/TLS certificate containing its public key. The client validates this certificate through a chain of trust anchored at a root CA.

2.2 CA Certification System

Certificates are issued by trusted Certificate Authorities (CAs). Their root certificates are pre‑installed in operating systems and browsers.

When a server requests an SSL certificate, it sends its public key and domain information to a CA, which signs the data with its private key, producing a certificate and a signature (certificate fingerprint).

Clients verify the server certificate by: Retrieving the issuer’s public key from the upper‑level certificate. Decrypting the certificate fingerprint (signature) with that public key to obtain sign1 . Recomputing the signature over the certificate data to obtain sign2 . Comparing sign1 and sign2 ; if they match, the certificate is authentic and untampered.

Note: RSA verification works by encrypting the signature with the private key and decrypting it with the public key.

Through this CA‑based verification, an attacker cannot obtain the symmetric AES key, preventing MITM attacks on HTTPS traffic.

Summary

We first examined why HTTP is insecure due to its clear‑text nature and demonstrated MITM attacks. Then we traced the evolution of security mechanisms—symmetric encryption, asymmetric RSA key exchange, and finally TLS/SSL with a CA‑based certificate chain—to explain how HTTPS protects against such attacks.