Why HTTP Is Insecure and How HTTPS Solves It: A Deep Dive into TLS Handshakes

Introduction

The article begins by highlighting two fundamental problems of the HTTP protocol: data is transmitted in clear text and the lack of authentication allows tampering and eavesdropping. These issues motivate the need for a more secure transport layer.

Proposed Solutions

Four solution ideas are discussed:

Symmetric encryption of data between client and server.

Asymmetric encryption of data.

Hybrid approach: use asymmetric encryption to negotiate a symmetric key, then encrypt data symmetrically.

Full HTTPS model: authenticate both parties, use a digital certificate, negotiate a key via asymmetric encryption, and finally protect data with symmetric encryption.

Solution four is identified as the most practical because it addresses both confidentiality and integrity while keeping performance acceptable.

Theoretical Foundations

Key cryptographic concepts are briefly introduced:

Hash functions : deterministic, irreversible functions that produce a fixed‑size digest (e.g., MD5, SHA families).

Symmetric encryption : same key for encryption and decryption (e.g., AES, DES, 3DES).

Asymmetric encryption : public key encrypts, private key decrypts (e.g., RSA). It also enables digital signatures.

Digital signatures : a hash of the data encrypted with the sender’s private key, providing authenticity and integrity.

Digital certificates : a public key bound to an identity by a trusted Certificate Authority (CA) using the CA’s private key.

HTTPS Overview

HTTPS is HTTP layered over TLS/SSL. TLS provides confidentiality, integrity, and authentication through a handshake that establishes a shared secret key.

TLS Handshake (TLS 1.2) – Step‑by‑Step

TCP handshake – establishes a TCP connection.

ClientHello – client lists supported TLS versions, cipher suites, and a random nonce.

ServerHello – server selects TLS version, cipher suite, sends its random nonce, session ID, and its certificate.

Certificate verification – client validates the server certificate using built‑in root CAs.

Key exchange – using ECDHE (Elliptic Curve Diffie‑Hellman) the client and server exchange public values and compute a shared secret K (the x‑coordinate of the resulting EC point). The secret is mixed with the nonces to derive the symmetric session key.

Handshake finished – both sides confirm that the handshake messages were not tampered with (using MACs based on the newly derived keys).

Application data – data is encrypted with the symmetric algorithm (e.g., AES‑256‑GCM) and integrity‑checked with SHA‑384.

The handshake also includes optional session resumption via Session ID or Session Ticket, which reduces latency for subsequent connections.

All solutions have trade‑offs; CA‑based certificates rely on the trustworthiness of the issuing authority, and compromised CAs can lead to forged certificates.

Practical Considerations

Implementing HTTPS locally often requires generating a self‑signed certificate with OpenSSL and adding it to the system’s trusted store. The article notes that the author’s development workflow uses a custom local domain (matching the login cookie domain) and that HTTPS is needed to preserve login state.

Conclusion

The article concludes that HTTPS solves the two major HTTP problems by combining digital certificates, asymmetric key exchange, and symmetric encryption. It provides a concise summary of cryptographic primitives, the TLS handshake, and practical steps for configuring HTTPS.

References

https://www.cloudflare.com/zh-cn/learning/ssl/keyless-ssl/

https://www.cloudflare.com/zh-cn/learning/ssl/how-does-ssl-work/

https://www.ssl.com/zh-CN/

https://zh.wikipedia.org/wiki/Curve25519

https://zh.wikipedia.org/wiki/SHA