Understanding HTTPS Design: From Symmetric Encryption to Digital Certificates

How to Achieve Real Security?

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

Only A and B have the ability to see the true content of their communication.

With this definition, the natural solution is to encrypt the messages.

Symmetric Encryption

In a simple chat scenario, a shared secret key S can encrypt and decrypt messages. As long as S is never disclosed and is strong, only A and B can read the messages.

However, on the World Wide Web the server cannot use the same symmetric key for all clients; that would be equivalent to no encryption.

Therefore each client must use a different symmetric key, but the server must somehow tell the client which key to use.

How to Determine the Symmetric Algorithm

The server must negotiate the algorithm with the client. Negotiation itself is not encrypted and can be intercepted, leading to a chicken‑egg problem.

How to Encrypt the Negotiation Process

Asymmetric encryption solves this: a private key encrypts data that anyone with the corresponding public key can decrypt, while only the holder of the private key can decrypt data encrypted with the public key.

Thus the server uses asymmetric encryption to protect the negotiation of the symmetric algorithm.

How to Obtain the Public Key

Clients need the server’s public key before they can start encryption. Two simple approaches are considered: (1) the server sends the public key directly to each client, (2) the server publishes the key on a remote server for clients to fetch. Approach 1 is chosen to avoid an extra request.

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

Using a Third‑Party Institution’s Public Key

To prevent tampering, a third‑party Certificate Authority (CA) signs the server’s public key. The CA’s private key encrypts the server’s public key, and the client uses the CA’s public key to verify it.

This introduces the concept of a digital certificate.

Digital Signatures to Prevent Certificate Substitution

Because a CA can issue certificates to many entities, a malicious intermediary could obtain a legitimate certificate from the same CA and substitute it. Digital signatures bind the certificate’s contents to a hash (e.g., MD5) that the client can recompute and compare.

How the Client Verifies a Certificate Locally

The certificate itself contains the method for generating its identifier. The client computes the identifier (e.g., MD5 of the certificate data) and checks it against the stored value; if they match, the certificate is authentic.

Clients also need the CA’s public key, which is pre‑installed in browsers and operating systems. The certificate lists the issuing CA, allowing the client to locate the correct public key locally.

If the browser or OS trust store is compromised, the whole verification chain fails.

How a CA Issues a Certificate to a Server

Server administrators generate a certificate signing request (CSR) and submit it to a CA. The CA validates the request and returns a signed certificate, which the administrator installs on the web server.

Putting It All Together

HTTPS uses the TLS handshake to securely negotiate a symmetric encryption algorithm, then uses that algorithm for the actual data transfer. The handshake relies on asymmetric encryption, digital certificates, and random numbers to protect against eavesdropping and tampering.

Can HTTPS Be Summarised in One Sentence?

Not really; HTTPS is a complex protocol that combines symmetric encryption, asymmetric key exchange, digital certificates issued by trusted CAs, and random values to ensure confidentiality, integrity, and authenticity of web communications.

Afterword

This article is a personal attempt to reconstruct the reasoning behind HTTPS. It should be regarded as a simplified explanation; any inaccuracies are welcome for correction.

Java团长

专注于Java干货分享

扫描上方二维码获取更多Java干货