Understanding HTTP, Its Vulnerabilities, and How HTTPS Secures Communication

# HTTP Protocol

HTTP is a text‑based application‑layer protocol defined originally by RFC 2616 and now split into six RFC 7230‑7235 specifications. 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=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
…

Because the payload is transmitted in clear text, HTTP is vulnerable to man‑in‑the‑middle (MITM) attacks. An attacker can read and modify messages, as illustrated by the example where a user’s post “I love JAVA” is changed to “I love PHP”.

1.3 Preventing MITM attacks

One naïve mitigation is to encrypt the payload with a symmetric algorithm such as AES. Both parties agree on an encryption method and exchange an AES key, but the key itself is still exposed in clear text during the handshake, allowing a sophisticated MITM to capture it.

A stronger approach uses asymmetric encryption (RSA). The server generates a public‑private key pair, sends the public key to the client, the client encrypts a freshly generated AES key with the server’s public key, and the server decrypts it with its private key. This establishes a shared secret without exposing the AES key.

However, an active MITM can impersonate both client and server, present its own certificate, and obtain the client‑generated AES key, thus breaking the protection.

# HTTPS Protocol

HTTPS = HTTP + SSL/TLS. The TLS handshake exchanges keys and then encrypts the traffic with symmetric cryptography. The server presents an X.509 certificate signed by a trusted Certificate Authority (CA). The client validates the certificate chain up to a root CA stored in the operating system.

Certificate validation works by using the issuer’s public key to verify the signature on the subordinate certificate; matching signatures prove the certificate has not been tampered with.

Because the public key is bound to the trusted CA hierarchy, a MITM cannot forge a valid certificate without compromising a CA, thereby preventing the interception and modification of HTTP traffic.

# Summary

The article first explains why plain HTTP is insecure, demonstrates MITM attacks, explores symmetric and asymmetric encryption attempts, and finally shows how HTTPS (TLS) and the CA trust model protect against such attacks.