Why HTTPS Is Secure: Deep Dive into TLS Handshake, Certificates, and Risks

HTTPS

As the cost of deploying HTTPS drops, most websites now use it. While many know HTTPS is safer than HTTP and have heard of 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 protocol achieve this security?

Is a site that uses HTTPS always safe?

This article explores the principles behind HTTPS security in depth.

How HTTPS Works

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

The overall process consists of a certificate verification stage and a data transmission stage.

① Certificate verification stage

The browser initiates an HTTPS request.

The server returns its HTTPS certificate.

The client checks whether the certificate is valid; if not, it raises an alert.

② Data transmission stage

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

The random number is encrypted with the server’s public key and sent to the server.

The server decrypts the random number with its private key.

The server uses this random number to derive a symmetric key, encrypts the response data, and sends it back.

Why Symmetric Encryption Is Used for Data Transfer

Asymmetric encryption is computationally expensive, making it unsuitable for the high‑frequency data exchange typical of HTTP. Moreover, only the server holds the private key, so symmetric encryption is required for efficient, two‑way data protection.

Why a CA Issues Certificates

Without a trusted CA, anyone could create a certificate, enabling classic man‑in‑the‑middle attacks. The article illustrates the attack flow with a diagram.

The attack steps include DNS hijacking, the attacker presenting its own certificate, encrypting traffic with a symmetric key derived from a stolen random number, and finally decrypting and re‑encrypting traffic to the legitimate server.

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 authorized certification authorities can issue certificates. Their trustworthiness is based on a web of trust: browsers store root certificates from trusted CAs and use them to verify the signature chain of presented certificates.

3. How does a browser validate a certificate?

When a server returns an SSL certificate, the browser checks:

Domain name and validity period.

Whether the issuing CA is trusted (by verifying the certificate chain against stored root certificates).

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

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

Only when all checks pass does the browser consider the certificate valid.

Question: If a certificate is public, couldn’t an attacker download it and use it for a man‑in‑the‑middle attack? Answer: The attacker would lack the private key. Without the private key, the attacker cannot decrypt data encrypted with the public key, so the attack fails.

4. Must certificates be issued by a CA?

Browsers only warn users when a self‑signed certificate is used; they do not block access. Technically, anyone can generate a certificate, but only CA‑signed certificates avoid security warnings. Early implementations (e.g., China Railway 12306) used manually installed private certificates.

What if the locally generated random number is stolen?

The certificate verification uses asymmetric encryption, but the data transmission uses symmetric encryption with a locally generated random number. HTTPS does not protect the random number itself; protecting it falls under endpoint security (antivirus, anti‑malware, browser updates, etc.).

Can HTTPS traffic be captured?

HTTPS encrypts data, so typical packet capture tools see only ciphertext. However, if a user explicitly trusts a proxy’s certificate, a man‑in‑the‑middle proxy can decrypt and re‑encrypt traffic, allowing inspection. This requires the user to install the proxy’s certificate.

Therefore, HTTPS prevents unnoticed eavesdropping but does not stop intentional interception by trusted proxies.

Summary

Key points in Q&A form:

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

Q: How does the transmission work? A: The client requests HTTPS, receives the server’s certificate, validates it, generates a random number, encrypts it with the server’s public key, the server decrypts it, and both sides use the derived symmetric key for data exchange.

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

Q: Can HTTPS be captured? A: Yes, if the user trusts a proxy’s certificate; otherwise, traffic remains encrypted.

Source: https://www.cnblogs.com/leap/p/11953836.html