Understanding HTTPS: From HTTP Vulnerabilities to Secure Communication

Before introducing HTTPS, the article reviews the HTTP protocol, noting that it operates at the application layer and transmits messages in clear text, making it vulnerable to interception and modification.

It shows a typical HTTP request and response:

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=HTTP

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
...

The article then describes man‑in‑the‑middle (MITM) attacks on HTTP, using a simple example where a user’s post is altered from “I love JAVA” to “I love PHP”. It explains that because HTTP traffic is plaintext, an attacker can read and modify both requests and responses.

To counter this, the article explores adding symmetric encryption (AES) to the communication, but points out that the encryption method and key are still exposed in the initial handshake, allowing an attacker to capture the AES key if the first exchange is intercepted.

It then introduces asymmetric encryption (RSA) to protect the key exchange: 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 server’s public key, and the server decrypts it with its private key. This prevents the attacker from obtaining the symmetric key.

However, the article notes that a sophisticated MITM can still act as a proxy, presenting its own public key to the client and establishing separate encrypted channels with both client and server, thereby still obtaining plaintext data.

Finally, the article explains how HTTPS (SSL/TLS) solves these problems. HTTPS combines SSL/TLS with HTTP, using a handshake that exchanges keys securely and then encrypts the data stream with symmetric encryption. The server presents an SSL certificate containing its public key; the client validates the certificate through a chain of trust anchored by root CA certificates pre‑installed in the operating system.

The certificate verification process involves checking the signature of each certificate in the chain using the issuer’s public key, ultimately confirming that the server’s certificate has not been tampered with. Because the public key is bound to a trusted CA, an attacker cannot forge a valid certificate without compromising a trusted CA.

By using this PKI‑based trust model, HTTPS prevents MITM attacks from stealing the symmetric AES key, ensuring confidentiality and integrity of the communication.

In summary, the article walks through the insecurity of HTTP, the evolution of security mechanisms, and how HTTPS, together with CA‑based certificate validation, provides robust protection against eavesdropping and tampering.