Understanding the Principles and Security Mechanisms of HTTPS

Everyone knows that HTTPS is more secure than HTTP and has heard of related concepts such as SSL, asymmetric encryption, and CA certificates, but many cannot answer three fundamental questions: why HTTPS is safe, how its underlying mechanisms work, and whether using HTTPS guarantees absolute security.

The article dives deep into the principles of HTTPS, first clarifying that while the data transmission is encrypted with symmetric encryption, asymmetric encryption is only used during the certificate verification stage.

Certificate verification stage:

The browser initiates an HTTPS request.

The server returns its HTTPS certificate.

The client validates the certificate’s legality and alerts the user if it is invalid.

Data transmission stage:

After a valid certificate is confirmed, 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 the random number to derive a symmetric encryption algorithm, encrypts the response data, and sends it back.

Why is symmetric encryption used for data transfer? Because asymmetric encryption is computationally expensive and unsuitable for the high‑frequency exchanges typical of HTTP, and only the server holds the private key, making asymmetric encryption a one‑way operation.

Why are CA certificates required? Without a trusted authority, anyone could create a certificate, enabling classic man‑in‑the‑middle (MITM) attacks. The article illustrates the MITM process, showing how an attacker can intercept traffic, present a forged certificate, and decrypt the communication.

How does a browser ensure a CA certificate’s legitimacy? It checks the certificate’s domain, validity period, and other fields; verifies the issuing authority against a locally stored root store; confirms the certificate has not been tampered with; and checks revocation status via CRL or OCSP.

The article also lists the typical contents of a certificate (issuer information, public key, organization details, domain, validity period, fingerprint, etc.) and explains that only certificates issued by trusted CAs avoid browser security warnings, although technically anyone can generate a self‑signed certificate.

Additional concerns such as the security of the locally generated random number, the possibility of packet capture, and the limits of HTTPS protection are discussed, emphasizing that HTTPS protects against passive eavesdropping but not against active, user‑authorized interception.

Finally, a concise Q&A summary recaps why HTTPS is secure, how the handshake works, why certificates are needed, and the reality of packet capture under HTTPS.