Why HTTPS Needs Both Symmetric and Asymmetric Encryption: A Deep Dive

Abstract: This article attempts to reconstruct the design process of HTTPS in order to understand why HTTPS looks the way it does. Readers are encouraged to set aside prior assumptions about HTTPS while following the reconstruction.

How to Achieve True Security?

Many immediately think of various encryption algorithms—symmetric, asymmetric, DES, RSA, etc.—but encryption algorithms are merely solutions. First we must define the problem domain: what does security mean?

Only A and B should be able to see the actual content of their communication.

For a simple A‑to‑B chat, the obvious solution is symmetric encryption, where a shared secret key S encrypts and decrypts messages.

In the web environment, using the same symmetric key for all clients is insecure. Each client must use a different symmetric algorithm without exposing the key.

How to Determine the Symmetric Algorithm

The server must tell each client which symmetric algorithm to use, which is done through negotiation.

Negotiation itself is not encrypted, so it could be intercepted. To protect the negotiation, we use asymmetric encryption.

Encrypting the Negotiation Process

Asymmetric encryption uses a private key for encryption and a public key for decryption (or vice‑versa). This allows the server to securely exchange the symmetric algorithm.

However, the server’s public key could be tampered with by a man‑in‑the‑middle. The solution is a third‑party Certificate Authority (CA) that signs the server’s public key.

Clients verify the CA’s signature; if verification succeeds, the public key has not been altered.

Digital Signatures Prevent Certificate Tampering

Certificates contain a method for generating a certificate identifier (e.g., MD5 hash). The client recomputes this identifier; if it matches, the certificate is authentic.

Browsers and operating systems maintain a trusted list of CA public keys, enabling local verification of certificates without contacting remote services.

If the trusted root is compromised, the whole system fails.

Putting It All Together

HTTPS secures client‑server communication by using symmetric encryption for data transfer, asymmetric encryption (with certificates signed by a CA) for securely negotiating the symmetric key, and digital signatures to ensure the integrity of the certificates themselves.

Understanding these mechanisms explains why HTTPS involves multiple round‑trips, why it can be slower than HTTP, and where performance optimizations can be applied.