Understanding HTTP Vulnerabilities and How HTTPS Secures Communication

Before using any website, especially for sensitive content, you should verify whether the connection is HTTPS because plain HTTP can be intercepted and altered by a man‑in‑the‑middle (MITM) attacker.

1. HTTP protocol – HTTP is a text‑based application‑layer protocol that works via request‑response messages. 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=HTTP

The corresponding response may 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

...

Because all data is transmitted in clear text, an attacker can read and modify both the request and the response.

2. HTTP MITM attack – The article gives an example where a user posts "I love JAVA" on a forum, but a MITM changes the content to "I love PHP". This demonstrates that HTTP provides no confidentiality or integrity.

3. Attempted protection with symmetric encryption – One might think to encrypt the payload with a shared secret (e.g., AES). Both parties agree on an encryption method and encrypt the message, but the key itself is still exchanged in clear text, so a MITM that intercepts the first handshake can obtain the AES key and decrypt all subsequent traffic.

4. Introducing asymmetric encryption (RSA) – To hide the symmetric key, the server generates an RSA key pair and publishes the public key. The client generates a random AES key (AES_KEY), encrypts it with the server’s public key to obtain AES_KEY_SECRET, and sends it to the server. The server decrypts it with its private key, obtaining the same AES_KEY, and then both sides use AES for the actual data transfer.

5. Advanced MITM using forged certificates – A sophisticated attacker can act as a proxy, generate its own RSA key pair, and present a fake certificate to the client. The client encrypts its AES_KEY with the attacker’s public key, allowing the attacker to recover the symmetric key and decrypt the entire session.

6. HTTPS (SSL/TLS) protocol – HTTPS combines HTTP with SSL/TLS. Although SSL has been largely replaced by TLS, the term is still used. SSL/TLS provides a handshake that securely exchanges keys and then uses symmetric encryption for data transfer.

The handshake involves the server sending an X.509 certificate containing its public key. The client validates this certificate through a chain of trust anchored at a root CA certificate that is pre‑installed in the operating system or browser.

7. CA trust chain – A Certificate Authority (CA) issues certificates to servers. The server’s certificate is signed by an intermediate CA, which in turn is signed by a root CA. Browsers verify the chain by checking each signature up to the trusted root. If the signatures match, the certificate is considered authentic and untampered.

During verification, the client uses the public key of the issuing CA to decrypt the certificate’s signature and compares it with a locally computed signature; a match confirms the certificate’s integrity.

8. Summary – By first exposing the weaknesses of plain HTTP and illustrating how MITM attacks can compromise data, the article shows the evolution of security mechanisms that lead to HTTPS. HTTPS prevents eavesdropping and tampering by using asymmetric encryption for key exchange, symmetric encryption for data, and a robust CA‑based certificate validation process.