Why HTTPS Combines Symmetric and Asymmetric Encryption: A Step‑by‑Step Reconstruction

How to Achieve True Security?

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

Only the communicating parties (A and B) can see the true content of their messages.

For a simple chat (A sends "hello" to B), symmetric encryption with a shared secret key S can satisfy this requirement.

In the web context, a server cannot use the same symmetric key for all clients; each client needs a distinct symmetric algorithm.

How to Determine the Symmetric Algorithm?

The server must negotiate with each client which symmetric algorithm to use, but the negotiation itself is vulnerable to interception.

To protect the negotiation, asymmetric encryption is introduced: a public key encrypts data that only the corresponding private key can decrypt, while the private key’s ciphertext can be decrypted by anyone holding the public key.

This resolves the key‑exchange problem: asymmetric encryption secures the negotiation of the symmetric algorithm.

Using Random Numbers

Random numbers generate fresh symmetric keys for each session, ensuring that every client‑server interaction uses a new algorithm.

How to Obtain the Public Key?

Two options exist: (1) the server sends the public key directly to each client, or (2) the client fetches it from a remote server. The article chooses option 1 for simplicity.

What If the Public Key Is Tampered?

If a man‑in‑the‑middle replaces the public key, the client cannot detect the attack. The solution is a third‑party authority that signs the server’s public key, creating a digital certificate.

The certificate contains the server’s public key encrypted with the CA’s private key; the client verifies it using the CA’s public key.

Digital Signatures Prevent Certificate Tampering

Certificates also embed a method (e.g., an MD5 hash) to generate a certificate identifier. The client recomputes this identifier and compares it to the one in the certificate; a match confirms authenticity.

Browsers and operating systems maintain a trusted list of CA public keys, enabling local verification without additional network requests.

Putting It All Together

HTTPS works by:

Using asymmetric encryption (public‑key cryptography) to securely exchange a symmetric key.

Employing a CA‑signed digital certificate to authenticate the server’s public key.

Applying the negotiated symmetric algorithm for the actual data transfer.

This layered design explains why HTTPS involves multiple round‑trips, why it incurs performance overhead, and where optimization opportunities lie.

Postscript

The author presents this reconstruction as a personal understanding of HTTPS, inviting corrections and acknowledging that the explanation is a simplified popular‑science overview.