Why HTTPS Combines Symmetric and Asymmetric Encryption: A Deep Design Walkthrough

Abstract: This article attempts to reconstruct the design process of HTTPS to understand why it looks the way it does, without claiming to describe the actual historical design.

Goal: Ensure that a message sent from A to B cannot be understood even if intercepted by a man‑in‑the‑middle.

Security means that only A and B have the ability to see the true content of their communication.

Only A and B can see the communication content.

For a simple chat scenario, symmetric encryption can be used: a shared secret key

S

encrypts and decrypts messages. As long as

S

remains secret, the problem domain is satisfied.

In the web environment, a single symmetric key for all clients is insufficient; each client must use a different symmetric algorithm.

How can the server tell each client which symmetric algorithm to use? The answer is negotiation.

The negotiation process itself is not encrypted and can be intercepted.

To protect the negotiation, asymmetric encryption is introduced. In asymmetric encryption, a public key encrypts data that only the corresponding private key can decrypt.

Using asymmetric encryption, the server and client can securely agree on a symmetric algorithm.

Random numbers are used to generate a fresh symmetric key for each session, which explains the many random values seen in the TLS handshake.

Obtaining the Server’s Public Key

The client needs the server’s public key before it can start the encrypted negotiation. Two possible approaches are:

Server sends the public key directly to each client.

Server stores the public key on a remote server that clients can request.

Approach 1 is chosen to avoid an extra request.

If the public key is tampered with during transmission, the client cannot verify it.

Because the client cannot distinguish whether the received public key comes from the legitimate server or a man‑in‑the‑middle, a digital certificate issued by a trusted third‑party (Certificate Authority, CA) is required.

The certificate contains the server’s public key encrypted with the CA’s private key. The client uses the CA’s public key (pre‑installed in browsers/OS) to verify the signature, ensuring the public key has not been altered.

Digital signatures also prevent a CA‑issued certificate for one organization from being reused by another malicious party.

Verification steps performed by the client:

Extract the certificate’s public key.

Compute a hash (e.g., MD5) of the certificate’s contents as specified inside the certificate.

Decrypt the certificate’s signature using the CA’s public key and compare the result with the computed hash.

If the hashes match, the certificate is authentic.

Browsers and operating systems maintain a trusted list of CA public keys, allowing clients to verify certificates locally without additional network requests.

If the browser/OS trust store is compromised, the security guarantees fail.

In summary, HTTPS relies on a combination of symmetric encryption for data confidentiality, asymmetric encryption for secure key exchange, and digital certificates signed by trusted CAs to protect the key exchange itself.

The TLS handshake involves multiple round‑trips to negotiate algorithms, exchange random values, and verify certificates before establishing a shared symmetric key for the session.