Understanding HTTP, MITM Attacks, and How HTTPS Secures Communication

Before discussing HTTPS, the article reviews the HTTP protocol, a text‑based application‑layer protocol defined by a series of RFCs (7230‑7235). HTTP communication follows a request‑response model, illustrated by example request and response messages.

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

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

The article then highlights a critical weakness of HTTP: all data is transmitted in clear text, making it vulnerable to man‑in‑the‑middle (MITM) attacks. An illustrative scenario shows how an attacker can read and modify a simple message posted by a user.

To mitigate this, the article first considers symmetric encryption (AES) of the payload. While encrypting the message hides its content, the key exchange remains insecure because the encryption method and secret key are still exposed in plaintext during the initial handshake.

To address key‑exchange vulnerabilities, the article introduces asymmetric encryption using RSA. The server generates a public‑private key pair, sends the public key to the client, and the client encrypts a randomly generated AES key (AES_KEY) with this public key, producing AES_KEY_SECRET. The server decrypts AES_KEY_SECRET with its private key to obtain the AES key, after which both sides use the AES key for symmetric encryption of subsequent traffic.

Client generates AES_KEY
Client encrypts AES_KEY with server's RSA public key → AES_KEY_SECRET
Client sends AES_KEY_SECRET to server
Server decrypts AES_KEY_SECRET with RSA private key → AES_KEY
Both parties use AES_KEY for encrypted communication

However, the article explains that a sophisticated MITM can still compromise this scheme by acting as both client and server, intercepting the key exchange, and obtaining the AES key.

Finally, the article introduces HTTPS, which combines SSL/TLS with HTTP. The TLS handshake performs a similar asymmetric key exchange, but the server presents an X.509 certificate signed by a trusted Certificate Authority (CA). The client validates the certificate by checking the signature chain up to a root CA that is pre‑installed in the operating system.

The CA trust model works as follows: the CA issues a certificate for the server, signing it with its private key; the client uses the CA’s public key (from the root certificate) to verify the signature, ensuring the server’s public key has not been tampered with. This prevents MITM attackers from inserting their own keys without a valid, trusted certificate.

In summary, the article walks through why plain HTTP is insecure, how encryption techniques evolve to protect data, and how HTTPS, backed by the CA infrastructure, provides a reliable defense against man‑in‑the‑middle attacks.