Why HTTPS Is Essential: A Deep Dive into HTTP, Encryption, and SSL/TLS

Introduction

HTTPS adds a security layer to HTTP. Many interviewees answer that HTTPS simply means "secure HTTP", uses port 443, and relies on asymmetric encryption, but the reality is far richer.

I. HTTP

HTTP (Hypertext Transfer Protocol) is an application‑layer protocol that transports hypertext and other media. It works over TCP/IP, encapsulating data in request and response messages.

HTTP message structure:

Evolution of HTTP

HTTP/0.9 (1991): only GET, informal standard.

HTTP/1.0 (1996): added many methods (POST, PUT, DELETE, etc.), no size limits.

HTTP/1.1 (1997): persistent connections, host header, chunked transfer.

HTTP/2 (2015): multiplexing, server push, header compression, binary framing; requires TLS (HTTPS).

Early versions opened a new TCP connection for each request, causing inefficiency. HTTP/1.1 introduced persistent (keep‑alive) connections, allowing multiple requests over a single TCP connection.

Security problems of plain HTTP:

Confidentiality: data is transmitted in clear text.

Integrity: intermediate devices can modify packets.

Authentication: vulnerable to man‑in‑the‑middle attacks.

II. Encryption Methods

Symmetric Encryption

Uses the same key for encryption and decryption. Fast and suitable for large data volumes, but key distribution is a challenge.

Common algorithms:

DES : 56‑bit key, now considered insecure.

3DES : applies DES three times with different keys, stronger but slower.

AES : supports 128/192/256‑bit keys, fast and widely adopted.

Advantages: simple, fast, efficient. Disadvantages: single key means if the key is compromised, security collapses. Typical use case: encrypting large data when key exchange is already secure.

Asymmetric Encryption

Uses a public‑key/private‑key pair. The public key encrypts, the private key decrypts.

Generate a key pair (public and private).

Sender encrypts data with the receiver’s public key.

Receiver decrypts with their private key.

Typical algorithm – RSA – relies on the difficulty of factoring large numbers. Keys of 1024‑bit are considered safe; 2048‑bit offers higher security.

Advantages: high security, no need to share secret keys.

Disadvantages: computationally intensive, slower.

Use case: securely exchanging symmetric keys, digital signatures, HTTPS.

How to Choose?

Symmetric only: both parties must already share a secret key, which is vulnerable to interception.

Asymmetric only: public key can be exchanged safely, but performance is low for bulk data.

Hybrid approach: use asymmetric encryption to exchange a symmetric key, then use symmetric encryption for the actual data transfer (the basis of HTTPS).

III. Certificate Authority (CA)

A CA issues digital certificates that bind a public key to an entity’s identity. Browsers trust certificates signed by recognized CAs.

Certificate creation involves generating a key pair and a Certificate Signing Request (CSR). The CA signs the CSR, producing a certificate containing the public key and the CA’s digital signature.

During an SSL/TLS handshake, the client verifies the certificate chain, checks validity dates and domain matching, then extracts the server’s public key.

IV. HTTPS

HTTPS is HTTP wrapped with SSL/TLS. SSL (renamed TLS in 1999) provides encryption, integrity, and authentication for any application protocol.

HTTPS handshake flow:

Client initiates a connection to the server’s port 443.

Server presents its CA‑signed certificate containing the public key.

Client validates the certificate (expiration, domain, chain of trust).

Client generates a random symmetric key, encrypts it with the server’s public key, and sends it.

Server decrypts the symmetric key with its private key.

Both sides now use the symmetric key to encrypt/decrypt HTTP payloads.

HTTPS addresses the three HTTP security issues:

Confidentiality – combines asymmetric encryption for key exchange with symmetric encryption for data.

Integrity – digital signatures from the CA ensure data has not been altered.

Authentication – the server’s certificate proves its identity.

HTTPS Pros and Cons

Pros : authenticates client and server, protects confidentiality and integrity, raises the cost of man‑in‑the‑middle attacks.

Cons : handshake adds latency (2–100× slower than plain HTTP), asymmetric encryption is computationally heavy, certificate trust chains can be compromised in some jurisdictions.

References

《图解HTTP》

RSA algorithm explanations

HTTPS migration guide

SSL/TLS protocol overview