How Does HTTPS Work? – The TLS Handshake Step by Step
Follow an HTTPS connection from client hello to encrypted request: key exchange, certificate verification, session keys, and resumption.
Before any HTTP request is sent over HTTPS, client and server perform a handshake that agrees how to encrypt, proves the server's identity, and derives keys. Everything after that is ordinary HTTP inside an encrypted channel.
1. The Client Hello
The client opens with what it supports: TLS versions, cipher suites, extensions, key-share material, and the hostname it wants — the last being how a server hosting many sites knows which certificate to present.
This message is sent in the clear, and its composition and ordering are characteristic of the client software, which is the basis of TLS fingerprinting.
2. The Server Response
The server selects a version and cipher suite from what was offered, sends its certificate chain, and contributes its own key-share material.
If nothing the client offered is acceptable, the handshake fails here — which is what a version or cipher mismatch actually looks like.
3. Certificate Verification
The client checks four things:
- Hostname — does the certificate cover the name requested?
- Validity — is now within its period?
- Chain — does it link to a trusted root, with intermediates present?
- Revocation — has it been withdrawn?
Any failure aborts the connection. This is the step that turns encryption into authenticated encryption, and it is the step disabling verification removes.
4. Deriving Session Keys
Both sides combine their key-share material to compute the same secret without it ever crossing the network. Symmetric keys derived from it encrypt the rest of the session.
Modern key exchange provides forward secrecy: because the material is ephemeral, recording the traffic and later obtaining the server's private key does not decrypt it.
5. Finishing
Each side sends a message proving it derived the same keys and saw the same handshake. That check makes tampering with earlier messages detectable.
From this point the connection carries encrypted application data — the HTTP request and response.
6. Round Trips and Resumption
TLS 1.3 completes the handshake in one round trip, and a resumed session can send data with none, using material from a previous connection.
This matters most on high-latency links, where handshake round trips were historically a visible share of page load time.
7. Where It Fails, and What Each Failure Means
| Failure | Cause |
|---|---|
| Protocol version alert | No shared TLS version |
| Handshake failure | No shared cipher suite, or policy refusal |
| Unknown authority | The chain does not reach a trusted root |
| Hostname mismatch | The certificate does not cover the requested name |
| Certificate expired | Renewal did not happen |
Forcing a specific version with a command-line client identifies the first two immediately.
8. Summary
An HTTPS connection begins with a handshake that negotiates version and ciphers, verifies the server's certificate, and derives session keys — after which ordinary HTTP flows encrypted.
Certificate verification is what makes the encryption meaningful, the client hello is visible and characteristic of the client, and TLS 1.3 reduced the cost to a single round trip or none on resumption.