Understanding the Principles and Security of HTTPS

Understanding the Principles and Security of HTTPS

HTTPS is now the default for most websites, yet many still wonder why it is considered safe, how it works under the hood, and whether it can guarantee complete security.

How HTTPS Works

HTTPS uses asymmetric encryption only during the certificate verification phase; the actual data transmission is protected by symmetric encryption. The overall process consists of two stages: certificate verification and data transmission.

Certificate verification stage:

Browser initiates an HTTPS request.

Server returns its SSL/TLS certificate.

Client validates the certificate’s legitimacy; if invalid, a warning is shown.

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.

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

Why Symmetric Encryption Is Used for Data Transfer

Asymmetric encryption is computationally expensive and unsuitable for the high‑frequency exchanges of HTTP. Moreover, only the server holds the private key, so symmetric encryption is needed for efficient two‑way communication.

Role of Certificate Authorities (CAs)

Certificates contain issuer information, public key, domain name, validity period, fingerprint, etc. CAs are trusted entities that issue certificates after verifying the applicant’s identity. Browsers consider a certificate legitimate when it passes domain and validity checks, is signed by a trusted root CA, has not been tampered with, and is not revoked (checked via CRL or OCSP).

Validate domain, expiration, and other fields.

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

Check for tampering.

Check revocation status via CRL or OCSP (OCSP can reduce round‑trips).

Man‑in‑the‑Middle (MITM) Attacks

If no CA is involved, anyone can create a self‑signed certificate, enabling classic MITM attacks: the attacker intercepts the client’s request, presents its own certificate, obtains the client‑generated random number, decrypts the traffic, forwards it to the legitimate server, and re‑encrypts the response for the client.

Can HTTPS Prevent Packet Capture?

HTTPS encrypts traffic, so passive sniffers only see ciphertext. However, if a user explicitly trusts a proxy’s certificate, the proxy can act as a MITM and decrypt the traffic. Thus HTTPS protects against unnoticed eavesdropping but not against authorized interception.

Summary (Q&A)

Why is HTTPS secure? It guarantees encrypted transmission and authenticates the server, preventing passive eavesdropping and many MITM attacks.

What is the transmission process? Client requests HTTPS, server returns a certificate, client validates it, generates a random number, encrypts it with the server’s public key, server decrypts with its private key, then both use the derived symmetric key for data exchange.

Why are certificates needed? They bind a public key to a verified identity, preventing MITM attacks and providing server identity proof.

Can HTTPS be captured? Yes, if the user trusts a malicious certificate; otherwise, the traffic remains encrypted.

END