Why HTTP Is Insecure and How HTTPS Stops Man-in-the-Middle Attacks
This article explains the fundamentals of HTTP, demonstrates how its plaintext nature enables man‑in‑the‑middle attacks, explores symmetric and asymmetric encryption attempts to mitigate the risk, and shows how HTTPS—through TLS handshakes, certificate validation, and a trusted CA hierarchy—provides robust protection.
1. HTTP Protocol
Before discussing HTTPS, we review the concept of HTTP.
1.1 Introduction to HTTP
HTTP is a text‑based transport protocol that operates at the application layer of the OSI model.
Communication follows a client‑server request‑response pattern. The original RFC 2616 has been split into six separate specifications (RFC 7230‑7235). A typical request and response look like:
Request
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=HTTPResponse
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>1.2 HTTP Man‑in‑the‑Middle Attack
HTTP is convenient but fundamentally insecure because all messages are transmitted in clear text.
Without encryption, an attacker can read and modify any request or response. For example, a user posts "I love JAVA" on a forum, a man‑in‑the‑middle changes it to "I love PHP", and the altered content is displayed.
This demonstrates that a passive eavesdropper can also actively tamper with the communication.
1.3 Mitigating MITM with Encryption
One might think of encrypting the payload with symmetric encryption (AES). The parties first agree on an encryption method, then encrypt the HTTP message.
Both sides agree on an encryption scheme.
Use AES to encrypt the message.
However, the encryption method and the secret key are still exchanged in clear text. If the initial exchange is intercepted, the key is compromised, allowing the attacker to decrypt subsequent traffic.
To protect the key, asymmetric encryption (RSA) can be used. The server generates a public‑private key pair and shares the public key with the client. The client creates a random AES key, encrypts it with the server’s public key, and sends the encrypted key (AES_KEY_SECRET) back. The server decrypts it with its private key, obtaining the shared AES key for symmetric encryption of the actual data.
While this prevents the attacker from seeing the AES key during normal operation, a sophisticated man‑in‑the‑middle can still perform a downgrade attack: it pretends to be the server, presents its own public key, captures the client‑generated AES key, and then decrypts the traffic.
2. HTTPS Protocol
2.1 Introduction to HTTPS
HTTPS is essentially HTTP over SSL/TLS. Although SSL has been largely superseded by TLS, the term SSL is still commonly used.
SSL/TLS also relies on an asymmetric handshake to exchange keys, followed by symmetric encryption for data transfer. The simplified handshake diagram is shown below.
The key point is that the server presents an SSL certificate containing its public key. The client validates this certificate using a trusted Certificate Authority (CA) hierarchy.
2.2 CA Trust Model
Certificates are issued by authoritative CAs whose root certificates are pre‑installed in operating systems.
When a server wants to use SSL, it sends its public key and domain information to a CA, which signs the data and returns a certificate. The certificate includes a signature (fingerprint) encrypted with the CA’s private key, forming a chain of trust.
For example, Baidu’s certificate is signed by GlobalSign G2, which in turn is signed by GlobalSign R1. Browsers verify the chain up to a trusted root certificate; if verification succeeds, the server’s certificate is trusted.
During validation, the client uses the issuer’s public key to decrypt the certificate’s fingerprint (sign1) and compares it with a locally computed signature (sign2). Matching signatures confirm the certificate’s integrity and authenticity.
This PKI‑based verification prevents attackers from stealing the AES key and performing MITM attacks on HTTP traffic.
Summary
We first examined why HTTP is insecure by illustrating man‑in‑the‑middle attacks, then traced the evolution of security techniques leading to HTTPS, and finally explained how TLS handshakes, certificate validation, and the CA trust model protect communications.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
MaGe Linux Operations
Founded in 2009, MaGe Education is a top Chinese high‑end IT training brand. Its graduates earn 12K+ RMB salaries, and the school has trained tens of thousands of students. It offers high‑pay courses in Linux cloud operations, Python full‑stack, automation, data analysis, AI, and Go high‑concurrency architecture. Thanks to quality courses and a solid reputation, it has talent partnerships with numerous internet firms.
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.