Why HTTP Is Insecure and How HTTPS Stops Man‑in‑the‑Middle Attacks
This article reviews the fundamentals of the HTTP protocol, explains why its plaintext transmission makes it vulnerable to man‑in‑the‑middle attacks, and details how HTTPS—through SSL/TLS, asymmetric key exchange, and CA certificate verification—protects data integrity and confidentiality.
1. HTTP Protocol
1.1 HTTP Overview
HTTP is a text‑based application‑layer protocol in the OSI model.
It operates via request‑response between client and server. The original RFC 2616 has been split into six separate specifications (RFC 7230‑7235). A typical request looks like:
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=HTTPA typical response looks like:
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 Man‑in‑the‑Middle (MITM) Attack on HTTP
Because HTTP transmits data in cleartext, an attacker can read and modify any request or response. For example, a user posting "I love JAVA" could have the content altered to "I love PHP" by a MITM.
Thus, HTTP is fundamentally insecure.
1.3 Preventing MITM with Encryption
One might try symmetric encryption (e.g., AES) to protect the payload, but the encryption method and key are still exchanged in cleartext, allowing the attacker to capture the key and decrypt later communications.
To avoid this, asymmetric encryption (RSA) is used: the server generates a public‑private key pair, sends the public key to the client, the client encrypts a randomly generated AES key with the public key, and the server decrypts it with its private key. Subsequent communication uses the shared AES key.
Even this can be subverted if the attacker issues their own fake public key, captures the encrypted AES key, and decrypts the traffic.
2. HTTPS Protocol
2.1 HTTPS Overview
HTTPS = SSL/TLS + HTTP. SSL has largely been replaced by TLS, but the term SSL is still commonly used.
SSL/TLS provides a handshake that exchanges keys and then secures the data channel with symmetric encryption.
The handshake involves the server presenting an SSL certificate containing its public key. The client validates this certificate through a chain of trust anchored by built‑in CA root certificates.
2.2 Certificate Authority (CA) Trust Model
Trusted CA root certificates are pre‑installed in operating systems. A server obtains a CA‑signed certificate, which includes a signature generated with the CA’s private key. The client verifies the signature using the CA’s public key, building a chain up to a trusted root.
If the signatures match, the certificate is considered authentic and the server’s public key can be trusted.
Certificate verification uses RSA: the CA signs the certificate with its private key, and the client verifies the signature with the CA’s public key.
Through this PKI model, the client can securely obtain the server’s public key, encrypt the symmetric AES key, and prevent MITM attackers from stealing it.
Summary
The article first explains why HTTP is insecure due to cleartext transmission and MITM vulnerabilities, then describes how encryption techniques evolve from symmetric to asymmetric methods, and finally shows how HTTPS, SSL/TLS, and the CA trust chain together to protect web 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.
Programmer DD
A tinkering programmer and author of "Spring Cloud Microservices in Action"
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.