Why HTTP Is Insecure and How HTTPS Stops Man-in-the-Middle Attacks
This article explains the fundamental weaknesses of HTTP, demonstrates how man‑in‑the‑middle attacks exploit clear‑text communication, and shows how HTTPS—through SSL/TLS handshakes, certificate validation, and CA hierarchies—protects web traffic from interception and tampering.
1. HTTP Protocol
Before discussing HTTPS, let's review HTTP.
1.1 Introduction to HTTP
HTTP is a text‑based application‑layer protocol in the OSI model.
It uses a request‑response model. The original RFC 2616 has been split into six RFCs (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=HTTPAnd a typical response:
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 Attack on HTTP
HTTP transmits data in clear text, making it vulnerable to interception and modification. An example shows a forum post being altered by an attacker.
Original post: "I love Java".
Attacker changes it to "I love PHP".
The user is mocked.
Because all request and response bodies are readable, HTTP is unsafe.
1.3 Preventing MITM Attacks
One might encrypt the payload with symmetric encryption (AES). The client and server agree on an encryption method, then encrypt the message.
Both parties agree on an encryption scheme.
Use AES to encrypt the payload.
However, the encryption method and key are still sent in clear text, so if the first exchange is intercepted, the key is compromised.
To protect the key, 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.
Even this can be subverted: a sophisticated MITM can act as both client and server, present its own certificate, capture the AES key, and decrypt the traffic.
2. HTTPS Protocol
2.1 Introduction to HTTPS
HTTPS = SSL/TLS + HTTP. SSL/TLS is also used with other application‑layer protocols such as FTP and WebSocket.
SSL/TLS performs a handshake to exchange keys, then uses symmetric encryption for data transfer.
The handshake involves the server presenting an SSL certificate containing its public key, which the client validates via a CA hierarchy.
2.2 CA Certification System
Certificates are issued by trusted Certificate Authorities (CAs). Their root certificates are pre‑installed in operating systems.
When a server wants an SSL certificate, it sends its public key and domain information to a CA, which signs it and returns the certificate. Browsers verify the certificate chain up to a trusted root.
During verification, the client uses the issuer’s public key to decrypt the certificate’s signature and compare it with a locally computed signature; a match confirms authenticity.
Summary
The article first explains why HTTP is insecure due to clear‑text transmission and MITM vulnerabilities, then describes how encryption techniques evolve, culminating in HTTPS, which uses SSL/TLS handshakes, certificates, and a CA hierarchy to protect against such attacks.
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.
Open Source Linux
Focused on sharing Linux/Unix content, covering fundamentals, system development, network programming, automation/operations, cloud computing, and related professional knowledge.
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.