Why HTTPS Needs Both Symmetric and Asymmetric Encryption (Explained)

Reconstructing HTTPS Design

This article attempts to step‑by‑step reconstruct the design process of HTTPS to understand why the protocol ends up the way it does, without claiming to describe the actual historical design.

How to Achieve True Security

For a simple chat where A sends a hello message to B, security means that even if a man‑in‑the‑middle intercepts the packet, it cannot learn the message content.

Encryption algorithms are only solutions; first we must define the problem domain: what is security? In this context, security means only A and B can see the true content of their communication.

Using a shared secret key S for both encryption and decryption satisfies this, as long as S is never disclosed to third parties.

However, in the Web environment the server cannot use the same symmetric key for all clients, because that would be equivalent to no encryption.

How to Encrypt the Negotiation Process

The server must use a different symmetric algorithm for each client, but the negotiation itself is unencrypted and vulnerable to interception. The solution is to use asymmetric encryption (public‑key cryptography) to protect the key‑exchange.

With asymmetric encryption, a private key can encrypt and anyone with the corresponding public key can decrypt, while data encrypted with the public key can only be decrypted by the private key holder.

How to Obtain the Public Key

Clients need the server’s public key before they can start encrypting. Two simple approaches are considered:

Server sends the public key directly to each client.

Server publishes the public key on a remote server for clients to fetch.

Approach 1 is chosen to avoid an extra request, but it raises the risk of a man‑in‑the‑middle replacing the key.

Using a Third‑Party Authority to Solve the Chicken‑Egg Problem

To prevent key substitution, a trusted third‑party (Certificate Authority, CA) signs the server’s public key. The CA’s private key encrypts the server’s public key, and clients use the CA’s public key to verify it.

However, if the CA issues certificates to malicious intermediaries, they could still substitute certificates. This leads to the need for digital signatures that bind the certificate to the server’s identity.

Digital Signatures and Certificate Validation

A certificate contains the server’s public key and a method for generating a certificate identifier (e.g., an MD5 hash). The client computes the identifier locally; if it matches the one in the certificate, the certificate is authentic.

The certificate identifier itself is encrypted with the CA’s private key, ensuring it cannot be tampered with.

Browsers and operating systems maintain a trusted list of CA public keys, allowing clients to verify certificates without contacting external services.

How a CA Issues a Certificate

The server generates a key pair, creates a certificate request, and sends it to the CA. The CA signs the request, producing a digital certificate that the server installs on its web server.

Putting It All Together

HTTPS uses asymmetric encryption to securely negotiate a symmetric key, then uses that symmetric key for the bulk of the data transfer. The CA‑signed certificate prevents man‑in‑the‑middle attacks on the key‑exchange.

Below are key diagrams illustrating the concepts: