Reconstructing the Design Process of HTTPS: From Symmetric and Asymmetric Encryption to Digital Certificates

Abstract: This article attempts to reconstruct the design process of HTTPS in order to understand why HTTPS looks the way it does. It does not claim to describe the actual historical design process, and readers are encouraged to set aside their pre‑existing knowledge of HTTPS while following the reconstruction.

We start with a simple chat example: A wants to send a "hello" message to B.

If we only consider security, the requirement is that even if a man‑in‑the‑middle intercepts the packet, it cannot learn the message content.

A’s hello message must remain unreadable to anyone other than B.

How can we achieve true security? Many immediately think of 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.

With the problem defined, the obvious solution is to encrypt the message. However, is encryption the only way? Perhaps future technologies could break the current communication assumptions.

For the simple A‑B model, symmetric encryption works: a shared secret key S encrypts and decrypts the message.

As long as the key S is not disclosed to third parties and remains strong, A and B can communicate securely.

In the WWW environment, the web server model is not that simple.

If the server used the same symmetric key for all clients, it would be equivalent to no encryption. The solution is to use a different symmetric key for each client.

But how does the server tell each client which symmetric algorithm to use? The answer is negotiation.

The negotiation itself is unencrypted and vulnerable to interception, leading to the classic "chicken‑egg" problem of encrypting the negotiation.

Asymmetric encryption solves this: a private key encrypts data that only the corresponding public key can decrypt, and vice‑versa.

Thus, the server can use asymmetric encryption to securely negotiate the symmetric algorithm.

To obtain the server’s public key securely, we cannot simply send it in the clear because it could be tampered with. The solution is a third‑party Certificate Authority (CA) that signs the server’s public key.

If the client can decrypt the signed certificate, it knows the public key has not been altered.

However, a CA can issue certificates to many entities, including malicious intermediaries, which leads to the need for digital signatures to detect tampering.

Clients verify certificates locally using the CA’s public key, which is pre‑installed in browsers and operating systems.

If the browser/OS trust store is compromised, the whole system fails.

In practice, the certificate contains a method (e.g., MD5 hash) to generate a certificate serial number; the client recomputes it and compares it to the embedded value, ensuring integrity.

Browsers and OSes maintain a trusted list of CA public keys, allowing them to validate certificates without contacting remote services.

Finally, the article summarizes that HTTPS requires symmetric encryption for data transfer, asymmetric encryption for key exchange, and digital certificates signed by trusted CAs to protect the key exchange from man‑in‑the‑middle attacks.

HTTPS cannot be reduced to a single sentence because of its complexity, but essentially it combines these mechanisms to provide secure client‑server communication.