TLS Handshake Explained: How HTTPS Actually Works

When you type https:// into your browser, a lot happens before you see the webpage. HTTPS is not a separate protocol. It is simply HTTP (the web protocol) running inside a TLS security tunnel that is carried over TCP (the reliable transport). This article walks through each layer, explains the TLS handshake, and shows how certificates are verified.

The Foundation: TCP

TCP (Transmission Control Protocol) is the workhorse that delivers data reliably between two machines. Before any application data can be sent, the client and server perform a three‑way handshake:

• SYN client says “I want to connect.”
• SYN‑ACK server agrees.
• ACK client confirms.

After this, a bidirectional, ordered, error‑checked channel exists. TCP does not encrypt anything; it just moves bytes.

The Security Layer: TLS

TLS (Transport Layer Security) is a protocol that runs on top of TCP. Its job is to turn the plain TCP pipe into an encrypted, authenticated, and integrity‑protected tunnel. The process of setting up this tunnel is called the TLS handshake.

What the Handshake Achieves

• Negotiation: client and server agree on a TLS version and cipher suite.
• Authentication: the server proves its identity using a digital certificate.
• Key exchange: both sides create a shared secret that only they know.
• Verification: they confirm that the handshake wasn’t tampered with.

Simplified Handshake Steps

The following diagram shows the messages exchanged. Note that the first three messages happen over the already‑established TCP connection.

• ClientHello – client sends supported TLS versions, cipher suites, and a random number.
• ServerHello – server picks a version and cipher suite, sends its own random number.
• Certificate – server sends its certificate (contains its long‑term public key, domain, and a CA signature).
• ServerKeyExchange – server sends an ephemeral (temporary) public key, signed with its long‑term private key.
• ClientKeyExchange – client sends its ephemeral public key.
• ChangeCipherSpec – signals that subsequent messages will be encrypted.
• Finished – both sides send an encrypted hash of the handshake to confirm it was not tampered with.

After the handshake, the actual HTTP data is sent inside encrypted TLS records.

The Purpose of ChangeCipherSpec

The ChangeCipherSpec message is a simple indicator that tells the other side: “From this point forward, I will encrypt all messages using the session keys we just agreed on.” It synchronises the encryption state. The Finished message that follows is the first encrypted message; it includes a hash of the entire handshake, allowing both sides to verify that no one tampered with the handshake.

How the Browser Verifies a Certificate

When the server sends its certificate, the browser must decide whether to trust it. It does not contact the Certificate Authority (CA) for every connection. Instead, it performs these checks:

• Chain of trust – The server’s certificate is usually not directly signed by a root CA. Instead, it’s signed by an intermediate CA, which is signed by a root CA. The server sends the full chain (its certificate + intermediates). The browser checks that each certificate in the chain is valid and that the root CA is in its trust store (a pre‑installed list of trusted root certificates that comes with the operating system or browser).
• Digital signature verification – Using the public key of the root CA (which is pre‑trusted), the browser verifies the signature on the intermediate certificate. Then, using the intermediate’s public key, it verifies the signature on the server’s certificate. If the signatures match, the browser knows that the server’s public key is vouched for by a trusted CA.
• Domain name – the certificate’s Subject Alternative Name (SAN) or Common Name must match the domain in the URL.
• Expiration – the certificate must be valid now.
• Revocation (optional) – the browser may check with the CA to see if the certificate has been revoked before its expiration.

If all checks pass, the browser accepts the server’s public key as authentic. If any check fails, the browser shows a security warning.

This process happens entirely on the client side—no live call to the CA is required for the basic signature verification, because the root CA’s public key is already trusted and stored locally.

Where Do the Private Keys Come From?

• Browser (client): For each new connection, the browser generates a temporary (ephemeral) private key entirely in memory. This key is used only during the handshake to compute the shared secret, then discarded. It is never transmitted.
• Server: The server also generates a temporary ephemeral private key for each session. This key is used together with the browser’s ephemeral public key to compute the shared secret. In addition, the server has a long‑term private key that corresponds to the public key inside its TLS certificate. This long‑term key is never used for encryption; it is used only to digitally sign the server’s ephemeral public key during the handshake, proving that the ephemeral key belongs to the legitimate server.

The diagram below shows the flow from ephemeral keys to the symmetric session keys that actually encrypt the HTTP data:

How is the actual HTTP data encrypted? From the shared secret derived during the handshake, both sides independently generate symmetric session keys (the same keys on both ends). These symmetric keys are used to encrypt and decrypt all HTTP traffic. The ephemeral private keys and the server’s long‑term private key are never used to encrypt or decrypt the web content itself.

Why forward secrecy? Because the shared secret is derived solely from the ephemeral key pair, the long‑term private key is only used for signing. Even if an attacker later steals the server’s long‑term private key, they cannot decrypt past sessions, the ephemeral keys used for those sessions are gone. This is forward secrecy.

The Application Layer: HTTP

HTTP (Hypertext Transfer Protocol) is the language of the web requests like GET /index.html and responses with status codes and content. In HTTPS, HTTP messages are never sent in the clear over the network; they are placed inside the encrypted TLS tunnel.

Putting It Together: HTTPS

HTTPS is not a separate protocol; it’s a URI scheme that tells the client: "Use HTTP, but wrap it in TLS over TCP." The formal description is HTTP over TLS over TCP.

So when you see a padlock in your browser, you know the stack is:

HTTP
│
TLS (encryption + authentication)
│
TCP (reliable transport)

Summary

• TCP provides reliable transport.
• TLS adds encryption, authentication, and integrity on top of TCP.
• HTTP is the application protocol that runs inside the TLS tunnel.
• HTTPS is simply HTTP over TLS over TCP – a scheme, not a separate protocol.
• The TLS handshake negotiates parameters, authenticates the server, establishes ephemeral keys, and confirms the connection.
• Certificates are verified by building a chain of trust to a pre‑trusted root CA.
• Forward secrecy ensures that past sessions cannot be decrypted even if the server’s long‑term private key is later stolen.
• Asymmetric encryption is used only during the handshake; symmetric encryption protects the actual HTTP data.
• Understanding this stack helps you debug connection issues, configure TLS termination correctly, and build secure systems with confidence.