Understanding HTTP and HTTPS: Protocol Basics, Man‑in‑the‑Middle Attacks, and Secure Communication

Before discussing HTTPS, the article reviews the basic concepts of the HTTP protocol, which operates at the application layer of the OSI model.

HTTP is a text‑based request/response protocol. The original RFC 2616 has been split into six separate specifications (RFC 7230‑7235). A typical HTTP request and response are shown:

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

Because HTTP transmits data in clear text, it is vulnerable to man‑in‑the‑middle (MITM) attacks. An example shows a user posting "I love JAVA" which is intercepted and altered to "I love PHP", demonstrating how an attacker can read and modify both requests and responses.

To mitigate MITM attacks, the article first suggests symmetric encryption (e.g., AES) of the payload, but notes that the encryption key itself can be exposed if the initial handshake is intercepted.

It then introduces asymmetric encryption (RSA) to protect the symmetric key. The server generates a public/private key pair, sends the public key to the client, the client encrypts the AES key with the server’s public key, and the server decrypts it with its private key. This exchange is illustrated with diagrams.

However, a sophisticated MITM can still perform a “proxy” attack by generating its own key pair, presenting a forged public key to the client, and thus obtaining the AES key. The article explains why this remains a threat.

Finally, the article transitions to HTTPS, describing it as SSL (now TLS) layered over HTTP. It outlines the SSL/TLS handshake, emphasizing that the server presents an SSL certificate containing its public key, which the client validates against a chain of trusted Certificate Authority (CA) root certificates.

The CA hierarchy is explained: root certificates are pre‑installed in operating systems, intermediate certificates sign server certificates, and the client verifies the signature chain by decrypting the certificate fingerprint with the issuer’s public key and comparing it to a locally computed signature.

Through this certificate verification process, HTTPS prevents MITM attackers from obtaining the symmetric AES key, thereby securing the communication.

The article concludes that understanding HTTP’s insecurity and the evolution to HTTPS provides a deeper grasp of web security principles.