Why HTTP Is Insecure and How HTTPS Stops Man‑in‑the‑Middle Attacks
This article explains the inherent insecurity of plain HTTP, demonstrates how man‑in‑the‑middle attacks can intercept and modify traffic, and shows how HTTPS—through SSL/TLS handshakes, RSA key exchange, and a trusted CA hierarchy—protects communications from such threats.
1. HTTP Protocol
Before discussing HTTPS, we review the concept of HTTP.
1.1 HTTP Overview
HTTP is a text‑based application‑layer protocol. A typical request and response look like the following:
<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) 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>1.2 Man‑in‑the‑Middle Attack on HTTP
Because HTTP traffic is plaintext, an attacker can read and modify any request or response. The article illustrates this with a simple example where a post saying “I love JAVA” is altered to “I love PHP”.
1.3 Preventing MITM Attacks
Encrypting the payload with symmetric AES seems to solve the problem, but the key exchange itself remains exposed. The article explains that using asymmetric RSA to encrypt the AES key prevents the attacker from obtaining the symmetric key.
In the RSA‑based scheme, the server generates an RSA key pair and sends the public key to the client. The client creates a random AES_KEY, encrypts it with the server’s public key (producing AES_KEY_SECRET), and sends it back. The server decrypts with its private key, establishing a shared secret for subsequent AES‑encrypted communication.
However, a sophisticated attacker can perform a “proxy” MITM by presenting its own RSA key pair to the client, thereby stealing the AES_KEY.
Thus, additional mechanisms are needed, which leads to HTTPS.
2. HTTPS Protocol
2.1 HTTPS Overview
HTTPS = HTTP over SSL/TLS. SSL/TLS is not limited to HTTP; it also secures FTP, WebSocket, and other application‑layer protocols. The handshake primarily exchanges keys and then uses symmetric encryption for data transfer.
The simplified diagram shows the server presenting an SSL certificate containing its public key, and the client validating the certificate.
2.2 Certificate Authority (CA) System
Certificates are issued by trusted CAs whose root certificates are pre‑installed in operating systems. The server sends a certificate signed by a CA; the client verifies the signature by traversing the chain up to a trusted root.
Verification works by decrypting the certificate’s signature with the issuer’s public key and comparing it to a locally computed hash. If they match, the certificate is authentic and untampered.
Through this PKI model, HTTPS prevents MITM attackers from injecting their own keys without detection.
Summary
The article first shows why plain HTTP is vulnerable to man‑in‑the‑middle attacks, then walks through incremental defenses—AES encryption, RSA key exchange, and finally the full HTTPS/SSL/TLS solution with CA‑based certificate validation.
Efficient Ops
This public account is maintained by Xiaotianguo and friends, regularly publishing widely-read original technical articles. We focus on operations transformation and accompany you throughout your operations career, growing together happily.
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.