How HTTPS Secures Web Traffic: Deep Dive into Certificates and Encryption

With the cost of HTTPS deployment decreasing, most websites now use HTTPS. While many know that HTTPS is safer than HTTP and are familiar with SSL, asymmetric encryption, and CA certificates, they often cannot answer three fundamental questions:

Why does using HTTPS make a connection secure?

How does the underlying HTTPS protocol work?

Is a site guaranteed to be safe just because it uses HTTPS?

HTTPS Implementation Principles

HTTPS encrypts transmitted data, but the actual data encryption uses symmetric encryption; asymmetric encryption is only used during the certificate verification phase.

The overall process consists of two stages: certificate verification and data transmission.

① Certificate Verification Stage

The browser initiates an HTTPS request.

The server returns its SSL/TLS certificate.

The client validates the certificate; if invalid, it raises an alert.

② Data Transmission Stage

After successful verification, the client generates a random number locally.

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

The server decrypts the random number using its private key.

Both parties derive a symmetric encryption key from the random number and use it to encrypt all subsequent traffic.

Why is symmetric encryption used for data transmission?

Asymmetric encryption is computationally expensive and unsuitable for the high‑frequency exchanges typical of HTTP, and it only provides one‑way encryption because only the server holds the private key. Therefore, HTTPS employs fast symmetric encryption for the actual data flow.

Why are CA certificates required?

Without a trusted Certificate Authority (CA), anyone could create a certificate, enabling classic man‑in‑the‑middle (MITM) attacks. The MITM process includes hijacking DNS, presenting a forged certificate, and decrypting the traffic using the intercepted random number.

How does a browser ensure the legitimacy of a CA certificate?

Certificates contain information such as the issuing authority, public key, organization details, domain, validity period, and fingerprint.

The legitimacy of a certificate relies on trusted root CAs that are pre‑installed in the operating system or browser. During verification, the browser checks:

Domain name and validity period.

Whether the issuing CA is trusted (by building a verification chain to a known root).

Whether the certificate has been tampered with (via CA server validation).

Whether the certificate has been revoked, using CRL or OCSP.

Summary (Q&A)

Q: Why is HTTPS secure? A: It guarantees encrypted transmission, preventing eavesdropping and data theft, and authenticates the server’s identity.

Q: What is the HTTPS transmission process? A: The client initiates a request, receives the server’s certificate, validates it, generates a random number, encrypts it with the server’s public key, the server decrypts it, and then both sides use symmetric encryption for the session.

Q: Why are certificates needed? A: They prevent MITM attacks and provide server identity verification.

Q: Can HTTPS traffic be captured? A: It can be intercepted if the user explicitly trusts a proxy’s certificate (e.g., a debugging tool); otherwise, the encrypted payload cannot be read.