Understanding HTTP, HTTPS, and How to Prevent Man‑in‑the‑Middle Attacks
This article explains the fundamentals of the HTTP protocol, illustrates its vulnerability to man‑in‑the‑middle attacks, demonstrates why plain HTTP is insecure, and shows how HTTPS, TLS/SSL, asymmetric encryption, and certificate authorities together protect communications from interception and tampering.
Before discussing HTTPS, the article reviews the basic concepts of the HTTP protocol, which operates at the application layer of the OSI model and uses plain‑text request‑response communication.
HTTP messages are defined by a set of RFCs (7230‑7235). An example request and response are shown:
<code>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</code><code>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
<html>...</html></code>Because HTTP transmits data in clear text, it is vulnerable to man‑in‑the‑middle (MITM) attacks. The article gives a simple illustration where a user’s post "I love Java" is altered to "I love PHP" by an attacker who can read and modify the traffic.
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 intercepted during the initial handshake.
It then introduces asymmetric encryption (RSA) to protect the symmetric key: the server generates an RSA key pair, publishes the public key, the client encrypts the AES key with the public key, and the server decrypts it with the private key. This prevents the attacker from obtaining the AES key directly.
However, a sophisticated MITM can still perform a “proxy” attack by presenting its own public key to the client and acting as a server to the real server, thereby stealing the AES key. The article explains that this is why HTTPS (HTTP over TLS/SSL) is needed.
HTTPS combines SSL/TLS with HTTP. Although SSL has been largely replaced by TLS, the article continues to refer to it as SSL for simplicity. During the TLS handshake, the server presents an X.509 certificate containing its public key; the client validates the certificate using a chain of trust anchored in built‑in root CA certificates.
The certificate authority (CA) system works as follows: a trusted CA issues certificates, signing them with its private key. Clients verify a server’s certificate by checking the signature against the CA’s public key, walking up the chain until a trusted root is reached.
Examples of a real‑world certificate (Baidu) are shown, illustrating the trust chain from GlobalSign G2 to GlobalSign R1 and finally to the root CA.
Finally, the article summarizes that understanding HTTP’s insecurity and the evolution of security mechanisms—symmetric encryption, asymmetric encryption, TLS/SSL, and CA verification—provides a solid foundation for grasping how HTTPS protects against MITM attacks.
Python Programming Learning Circle
A global community of Chinese Python developers offering technical articles, columns, original video tutorials, and problem sets. Topics include web full‑stack development, web scraping, data analysis, natural language processing, image processing, machine learning, automated testing, DevOps automation, and big data.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.