Understanding HTTP, Its Vulnerabilities, and How HTTPS Secures Communication

Click the blue "Architecture Abstract" to follow the author and add a star to receive daily technical content at 09:25.

1. HTTP Protocol

1.1 Introduction to HTTP

HTTP is a text‑based transport protocol that operates at the Application Layer of the OSI model.

HTTP communication follows a request‑response model. The original RFC 2616 has been split into six separate specifications (RFC 7230‑7235). A typical request and response look like:

Request

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

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

1.2 HTTP Man‑in‑the‑Middle (MITM) Attack

Because HTTP transmits data in clear text, an attacker can eavesdrop and modify both requests and responses. For example, a user posts "I love JAVA" on a forum; a MITM changes it to "I love PHP" and the user is mocked.

Original post: I love JAVA

MITM modifies it to: I love PHP

The user is ridiculed.

This demonstrates that any plaintext HTTP communication is vulnerable to interception and tampering.

1.3 Preventing MITM Attacks

One might think of encrypting the payload with symmetric encryption (e.g., AES). However, the encryption method and key are still exchanged in clear text, allowing an attacker who captures the first handshake to obtain the key and decrypt subsequent traffic.

To protect the key, asymmetric encryption (e.g., RSA) can be used. The server generates a public‑private 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 ( AES_KEY_SECRET ), and sends it back. The server decrypts it with its private key to obtain the AES_KEY , which is then used for symmetric encryption of the actual data.

Even with this approach, a sophisticated MITM can act as a rogue server, present its own public key, capture the client‑generated AES_KEY , and thus decrypt the traffic.

2. HTTPS Protocol

2.1 Introduction to HTTPS

HTTPS is essentially SSL + HTTP . Modern implementations use TLS instead of SSL, but the term SSL is still commonly used. SSL/TLS is not limited to HTTP; it also secures protocols such as FTP and WebSocket.

The handshake process mirrors the asymmetric encryption described earlier: the client and server exchange keys, then use symmetric encryption for the bulk of the communication.

2.2 CA Certification System

During the TLS handshake, the server presents an SSL certificate containing its public key. The client validates this certificate using a chain of trust anchored at a Root CA certificate that is pre‑installed in the operating system.

Authority Certification Authority (CA) issues certificates. The CA’s own certificate is trusted as a root.

Server obtains a CA‑signed certificate by sending its public key and identifying information to the CA. The CA signs the certificate with its private key, producing a certificate fingerprint.

When a client (browser) receives the server’s certificate, it verifies the signature by decrypting the fingerprint with the CA’s public key and comparing it to a locally computed signature. If they match, the certificate is trusted and has not been tampered with.

This PKI mechanism prevents a MITM from stealing the AES_KEY because the attacker cannot forge a valid certificate without the CA’s private key.

Summary

We first examined why HTTP is insecure due to its susceptibility to MITM attacks, then traced the evolution of security techniques culminating in HTTPS, which combines asymmetric key exchange, symmetric encryption, and a robust CA certification system to ensure safe communication.