Why Does HTTPS Need Both Symmetric and Asymmetric Encryption? A Step‑by‑Step Walkthrough

Abstract: The piece attempts to recreate the design process of HTTPS, encouraging readers to set aside pre‑existing notions and follow a logical reconstruction from a basic chat example to the full TLS handshake.

Defining the Security Problem

We begin with a minimal chat application where A sends a "hello" to B. The goal is that even if a man‑in‑the‑middle intercepts the packet, the message content remains unreadable. This defines the security requirement: only A and B can see the true content.

Symmetric Encryption for Direct Communication

For a closed pair of participants, a single shared secret key S can encrypt and decrypt messages. As long as S stays secret, confidentiality is achieved.

Why Symmetric Encryption Alone Fails on the Web

In a WWW setting the server cannot share the same secret with every client; doing so would expose the key to anyone who can intercept traffic. Each client must use a distinct symmetric key, but the server must also keep those keys secret.

Negotiating the Symmetric Algorithm

The server must tell each client which symmetric algorithm to use. This negotiation itself is vulnerable to interception, leading to a chicken‑egg problem: encrypting the negotiation with the same symmetric key does not solve the issue.

Introducing Asymmetric Encryption for Key Exchange

Asymmetric cryptography solves the negotiation problem: a public key can be freely distributed, while only the holder of the matching private key can decrypt. The server’s public key encrypts the symmetric key; the client uses the server’s private key to decrypt.

Distributing the Server’s Public Key Securely

Simply sending the public key over an insecure channel allows a man‑in‑the‑middle to replace it. Two naive solutions are considered: (1) the server pushes the key to each client, (2) the key is hosted on a remote server for clients to fetch. The article chooses the first to avoid an extra request.

Digital Certificates and Certificate Authorities (CAs)

To prevent public‑key substitution, a trusted third party (CA) 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, plus metadata and a signature.

Clients verify the certificate by decrypting the signature with the CA’s public key (which browsers and operating systems ship with a built‑in list of trusted CAs). This ensures the public key truly belongs to the intended server.

Certificate Validation and Digital Signatures

The certificate also includes a method for generating a unique identifier (e.g., an MD5 hash of its contents). The client recomputes this identifier and compares it to the one stored in the certificate; a match confirms integrity.

Full TLS Handshake Overview

The article concludes with a complete TLS handshake diagram, illustrating the sequence of messages that establish a shared symmetric key, authenticate the server via its certificate, and finally protect application data with symmetric encryption.

Takeaway

HTTPS combines symmetric encryption (for efficiency) with asymmetric encryption and digitally signed certificates (for secure key exchange and authentication). Understanding each component’s role clarifies why the protocol involves multiple round‑trips and why its performance differs from plain HTTP.