Why HTTPS Is Secure: From HTTP Vulnerabilities to TLS and CA Trust
HTTPS secures web communication by replacing plaintext HTTP with TLS encryption, using asymmetric key exchange to protect symmetric keys, and relying on a hierarchical CA certificate chain to verify server identities, thereby preventing man‑in‑the‑middle attacks that exploit HTTP’s unencrypted traffic.
1. HTTP Protocol
Before discussing HTTPS, the article reviews the basics of HTTP, a text‑based application‑layer protocol defined by RFC 7230‑7235. A typical HTTP request and response are shown:
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=HTTPHTTP/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.1 HTTP Man‑in‑the‑Middle (MITM) Attack
Because HTTP transmits data in clear text, an attacker can read and modify the traffic. The article illustrates this with a story: Xiao Ming posts “I love JAVA” on a forum; a MITM changes the content to “I love PHP”, and the altered post is then mocked by others. This demonstrates that any HTTP request or response can be intercepted and altered.
1.2 Attempted Protection with Symmetric Encryption
The author suggests encrypting the payload with a symmetric algorithm (AES) after the client and server agree on an encryption method. However, the key exchange itself is still in clear text, so if the initial handshake is intercepted, the AES key can be stolen, allowing the attacker to decrypt subsequent traffic.
1.3 Using Asymmetric Encryption (RSA) for Key Exchange
To hide the symmetric key, the article proposes RSA‑based key exchange: the server generates an RSA key pair, sends the public key to the client, the client creates an 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 to obtain the AES key, and both sides then use AES for the actual data transfer.
Even this scheme can be subverted: a sophisticated MITM can act as a fake server, present its own RSA public key to the client, capture the client‑generated AES key, and then decrypt the traffic.
2. HTTPS Protocol
2.1 HTTPS Overview
HTTPS is essentially HTTP over SSL/TLS. Although SSL has been largely superseded by TLS, the article continues to refer to it as SSL for simplicity. The SSL/TLS handshake establishes a shared secret (via asymmetric cryptography) and then protects the data channel with symmetric encryption.
The handshake diagram (simplified) shows the client receiving the server’s SSL certificate, verifying it, and then using the certificate’s public key to encrypt the symmetric key.
2.2 Certificate Authority (CA) Trust Chain
The client validates the server’s certificate by checking the hierarchical chain of trust anchored in root CA certificates that are pre‑installed in the operating system. The article uses Baidu’s certificate as an example, showing that Baidu’s certificate is signed by GlobalSign G2, which in turn is signed by GlobalSign R1, ultimately linking to a trusted root.
During verification, the client extracts the signature (sign2) from the server’s certificate, decrypts the certificate fingerprint using the issuer’s public key to obtain sign1, and compares the two signatures. Equality confirms that the certificate has not been tampered with and is authentic.
Because the certificate verification relies on RSA signatures, a MITM cannot forge a valid certificate without possessing a trusted CA’s private key, thus preventing the attacker from stealing the AES key and modifying the encrypted HTTP traffic.
Summary
The article first demonstrates why plain HTTP is insecure due to its clear‑text nature and susceptibility to MITM attacks. It then explores incremental defenses—symmetric encryption and RSA‑based key exchange—showing their limitations when the key exchange is not authenticated. Finally, it explains how HTTPS, through TLS handshakes and a CA‑based certificate trust chain, provides end‑to‑end confidentiality and integrity, effectively mitigating the MITM threats described earlier.
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.