Why HTTP Is Dangerous and How HTTPS Protects You from Man‑in‑the‑Middle Attacks
This article explains the insecurity of plain HTTP, demonstrates how man‑in‑the‑middle attacks can intercept and modify traffic, and details how HTTPS using SSL/TLS, asymmetric key exchange, and CA‑based certificate verification secures web communications.
When browsing the web, using HTTP leaves data exposed to man‑in‑the‑middle (MITM) attacks, while HTTPS secures the communication.
1. HTTP Protocol
HTTP is a text‑based application‑layer protocol. A typical request and response look 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=HTTPThe server replies with:
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>Because the messages are sent in clear text, an attacker can read and modify them. The article illustrates this with an example where a user’s post “I love JAVA” is altered to “I love PHP”.
1.3 Preventing MITM with Encryption
One might try to encrypt the payload with a symmetric key (AES), but if the key is exchanged in clear text the attacker can capture it and decrypt later traffic.
Using asymmetric encryption (RSA) solves the key‑exchange problem: 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 AES key.
2. HTTPS Protocol
HTTPS = HTTP over SSL/TLS. The SSL/TLS handshake establishes a secure channel by exchanging certificates and negotiating a symmetric session key.
Certificates are issued by trusted Certificate Authorities (CAs). Browsers contain root CA certificates; they verify a server’s certificate by checking the signature chain up to a trusted root.
During verification the browser uses the CA’s public key to decrypt the certificate’s signature and compares it with a locally computed hash; a match confirms the certificate has not been tampered with.
Summary
The article first shows why HTTP is insecure due to clear‑text transmission and MITM attacks, then explains how HTTPS, through SSL/TLS handshakes, asymmetric key exchange, and CA‑based certificate verification, protects the communication.
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.