Why HTTPS Is Truly Secure: Deep Dive into Its Principles and Pitfalls

As the cost of deploying HTTPS decreases, most websites now use the HTTPS protocol.

People know HTTPS is safer than HTTP and have heard of SSL, asymmetric encryption, and CA certificates, but may struggle to answer three fundamental questions:

Why does using HTTPS guarantee security?

How does HTTPS work under the hood?

Is a site that uses HTTPS always safe?

This article explains the security of HTTPS from first principles.

How HTTPS Works

HTTPS secures data transmission by encrypting the payload with symmetric encryption, while asymmetric encryption is used only during the certificate‑validation phase.

The overall process consists of a certificate‑validation stage and a data‑transfer stage.

Certificate‑validation stage

The browser initiates an HTTPS request.

The server returns its HTTPS certificate.

The client verifies the certificate’s validity; if invalid, it raises an alert.

Data‑transfer stage

After a valid certificate is confirmed, the client generates a random number locally.

The client encrypts the random number with the server’s public key and sends it to the server.

The server decrypts the random number with its private key.

The server uses the random number to derive a symmetric‑encryption algorithm and encrypts the response data.

Why symmetric encryption for data?

Asymmetric encryption is computationally expensive and unsuitable for the high‑frequency exchanges of HTTP. Moreover, only the server holds the private key, so asymmetric encryption can only provide one‑way authentication; therefore, the actual data payload is encrypted symmetrically.

Why a CA‑issued certificate is needed

Without a trusted Certificate Authority, anyone could create a certificate, enabling classic man‑in‑the‑middle attacks.

The attack proceeds as follows:

The local request is hijacked (e.g., DNS hijacking) and sent to the attacker’s server.

The attacker returns its own certificate.

The client encrypts a random number with the attacker’s public key and sends it.

The attacker, possessing the random number, decrypts the symmetric‑encrypted traffic.

The attacker forwards the request to the legitimate site and receives the encrypted response.

Using the same symmetric key, the attacker decrypts the response and re‑encrypts it for the client.

The client finally decrypts the data with the symmetric key.

Because the client cannot verify the certificate chain, it does not realize the traffic is being intercepted.

How browsers verify CA certificates

1. What information does a certificate contain?

Issuer information

Public key

Organization details

Domain name

Validity period

Fingerprint

…

2. On what basis is a certificate considered legitimate?

Only recognized, accredited authorities can issue certificates; browsers trust certificates signed by these authorities.

3. How does the browser validate a certificate?

Check domain name, validity period, and other fields.

Verify the certificate’s chain of trust against locally stored root CA certificates.

Confirm the certificate has not been tampered with (using the CA’s public key).

Check revocation status via CRL or OCSP; OCSP reduces round‑trips to the CA.

Q&A Summary

Q: Why is HTTPS secure? A: It guarantees secure transmission, prevents eavesdropping, and authenticates the website.

Q: What is the HTTPS transmission process? A: The client requests HTTPS, the server returns a certificate, the client validates it, generates a random number, encrypts it with the server’s public key, the server decrypts it, and subsequent data exchange uses symmetric encryption.

Q: Why are certificates needed? A: They prevent man‑in‑the‑middle attacks and provide site identity.

Q: Can HTTPS be sniffed? A: Yes, if the user explicitly trusts a proxy or installs a custom certificate; HTTPS only protects against unnoticed interception.

Source: https://blog.leapmie.com/archives/418/ (originally from the “51 CTO技术栈” public account).