Why HTTPS Is Secure: From HTTP Vulnerabilities to TLS Handshake
The article explains HTTP’s plaintext nature and its susceptibility to man‑in‑the‑middle attacks, then details how HTTPS (TLS) uses asymmetric key exchange, certificates, and a trusted CA hierarchy to establish encrypted communication and prevent such attacks.
1. HTTP Protocol
HTTP is a text‑based application‑layer protocol that follows a request‑response model. 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 corresponding response might be:
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 payload is transmitted in clear text, HTTP is vulnerable to man‑in‑the‑middle (MITM) attacks.
1.1 HTTP MITM Example
In a simple scenario, a user named Xiao Ming posts the message "I love JAVA" on a forum. An attacker intercepts the traffic and modifies the content to "I love PHP", leading to ridicule. This demonstrates that an MITM can read and alter any HTTP request or response.
1.2 Attempted Protection with Symmetric Encryption
One might try to encrypt the HTTP payload using a symmetric algorithm such as AES. The steps are:
Both parties agree on an encryption method.
The client generates an AES key (AES_KEY) and encrypts the HTTP body with it.
However, the encryption method and the AES key are exchanged in clear text during the first connection, allowing an attacker to capture the key and decrypt subsequent traffic.
1.3 Using Asymmetric Encryption (RSA) for Key Exchange
To hide the AES key, RSA is introduced:
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 AES_KEY_SECRET with its private key to obtain AES_KEY, and thereafter all communication is encrypted with AES.
This scheme prevents the attacker from directly seeing the AES key, but a sophisticated MITM can still perform a certificate‑spoofing attack: the attacker presents its own RSA key pair to the client, obtains the client‑generated AES_KEY, and then decrypts the traffic.
2. HTTPS Protocol
2.1 HTTPS Overview
HTTPS is essentially HTTP over SSL/TLS. Although SSL has been largely replaced by TLS, the term SSL is still commonly used. The TLS handshake performs a key exchange (often using RSA or Diffie‑Hellman) and then secures the data channel with symmetric encryption.
The handshake can be visualised as follows (simplified diagram):
The crucial difference from the naïve RSA scheme is the use of a trusted certificate issued by a Certificate Authority (CA).
2.2 CA Trust Chain
Certificates are signed by authoritative CAs. Root CA certificates are pre‑installed in operating systems. An intermediate CA signs the server’s certificate, forming a chain of trust.
When a client (e.g., a browser) connects to a server, it receives the server’s certificate and validates the chain up to a trusted root. For example, Baidu’s certificate is signed by GlobalSign G2, which in turn is signed by GlobalSign R1, ultimately rooted in a system‑installed CA.
2.3 Certificate Verification Process
The client extracts the issuer’s public key from the upper‑level certificate, uses it to decrypt the signature (sign1) on the server’s certificate, and recomputes the expected signature (sign2) using the server certificate’s data. If sign1 equals sign2, the certificate is authentic and untampered.
This verification relies on RSA: the CA signs the certificate with its private key, and the client verifies the signature with the CA’s public key.
3. Summary
The article first demonstrates why plain HTTP is insecure due to its clear‑text transmission and susceptibility to MITM attacks. It then walks through progressive defenses—from symmetric AES encryption to RSA‑based key exchange—and finally shows how HTTPS, through TLS handshakes, CA‑signed certificates, and rigorous certificate validation, prevents attackers from stealing the symmetric keys and tampering with 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.
Linux Tech Enthusiast
Focused on sharing practical Linux technology content, covering Linux fundamentals, applications, tools, as well as databases, operating systems, network security, and other technical 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.