Why HTTPS Needs Both Symmetric and Asymmetric Encryption Explained

Abstract: This piece 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.

We start not with HTTP but with a simple chat scenario where A sends a "hello" message to B. The goal is that even if a man‑in‑the‑middle intercepts the packet, it cannot reveal the content.

How to achieve true security?

Many think of encryption algorithms (symmetric, asymmetric, DES, RSA, etc.), but encryption is only a solution. First we must define the problem domain: what does security mean?

Only A and B can see the true content of their communication.

Given this domain, the obvious solution is to encrypt the message. For a simple A‑B model, symmetric encryption works: a shared secret key S encrypts and decrypts.

If the key S remains secret, the problem is solved because only A and B know S.

In the web world, the server cannot use the same symmetric key for all clients; that would be no encryption at all.

Thus each client must use a different symmetric algorithm (or key). How can the server tell each client which algorithm to use without exposing the key?

How to determine the symmetric algorithm

The server must negotiate with each client. Negotiation itself is unencrypted and vulnerable to interception, so we need to protect the negotiation.

How to encrypt the negotiation

We use asymmetric encryption: a private key encrypts data that anyone with the public key can decrypt, while data encrypted with the public key can only be decrypted with the private key.

This allows the server to securely send the symmetric key to each client.

However, the public key itself could be tampered with by a man‑in‑the‑middle. To solve this, we introduce a third‑party certificate authority (CA) that signs the server’s public key.

The CA’s private key encrypts the server’s public key, producing a digital certificate. The client can verify the certificate using the CA’s public key, which is pre‑installed in browsers/OS.

To prevent a malicious intermediary who also holds a certificate from the same CA from swapping certificates, digital signatures are used: the certificate includes a hash (e.g., MD5) of its contents signed by the CA’s private key.

The client validates the signature, ensuring the certificate has not been altered.

In practice, browsers and operating systems maintain a trusted list of CA public keys. When a certificate arrives, the client looks up the issuing CA and verifies the signature.

How a CA issues a certificate

The server administrator generates a key pair, creates a certificate signing request, and sends it to the CA. The CA verifies the request, signs the server’s public key, and returns the certificate, which the administrator installs on the server.

Putting it all together

During the TLS handshake, the client and server use asymmetric encryption (with the server’s certificate) to securely exchange a random value that becomes the symmetric key for the session. All subsequent data is encrypted with this symmetric key, providing confidentiality and integrity.

Thus HTTPS combines symmetric encryption for performance with asymmetric encryption and digital certificates for secure key exchange and authentication.

HTTPS why it is complex

Symmetric vs asymmetric encryption

Digital certificates and CAs

TLS handshake overview