diagrams
Networking

HTTPS Handshake

The HTTPS handshake is the full connection establishment sequence for a secure web request, combining TCP connection setup, TLS negotiation, and the first encrypted HTTP exchange into a single observable flow.

diagram.mmd — sequence
Edit in Graphlet →
HTTPS Handshake sequence diagram
About Source

The HTTPS handshake is the full connection establishment sequence for a secure web request, combining TCP connection setup, TLS negotiation, and the first encrypted HTTP exchange into a single observable flow.

HTTPS is HTTP layered on top of TLS (Transport Layer Security). Understanding the complete handshake helps developers reason about latency, certificate errors, and the security properties of each step.

DNS Resolution happens first — the browser resolves the hostname to an IP via the DNS system. This can be a significant source of latency on first visit; CDNs and DNS prefetching () help here.

TCP Connection: A TCP socket is opened with the standard three-way handshake (SYN/SYN-ACK/ACK). This establishes a reliable, ordered byte stream between client and server.

TLS Negotiation (see also TLS Handshake for the deep-dive) begins immediately after TCP is established. The client sends a ClientHello advertising supported cipher suites and TLS versions. The server responds with ServerHello selecting a cipher suite and sends its X.509 certificate. The client validates the certificate against trusted CAs (see TLS Certificate Validation), then performs key exchange. Both sides derive symmetric session keys and confirm with Finished messages.

Encrypted HTTP begins once the TLS handshake completes. All HTTP request and response data — headers, body, cookies, and even the URL path — is encrypted at this point. An observer on the network can see the destination IP and SNI hostname from the TLS handshake, but nothing about the specific request content.

HTTP Strict Transport Security (HSTS) allows servers to instruct browsers to always use HTTPS for a domain, preventing protocol downgrade attacks. With TLS 1.3, the full handshake (TCP + TLS) completes in 2 RTTs for a new connection and 1 RTT for session resumption.

Free online editor
Edit this diagram in Graphlet
Fork, modify, and export to SVG or PNG. No sign-up required.
Open in Graphlet →

Frequently asked questions

The HTTPS handshake is the complete connection establishment sequence for a secure web request: DNS resolution to find the server IP, a TCP three-way handshake to establish a reliable transport connection, and a TLS negotiation to authenticate the server and derive symmetric encryption keys — all before any HTTP data is exchanged.
For a new connection with TLS 1.3, the total is 2 RTTs: one for the TCP handshake and one for the TLS handshake. DNS adds 0–100ms on a cold lookup. With TLS session resumption, the TLS phase drops to 1 RTT, reducing the total to 1.5 RTTs (TCP + abbreviated TLS). QUIC/HTTP/3 collapses both to 1 RTT.
Once TLS is established, all HTTP request and response data is encrypted — headers, body, URL path, cookies, and query parameters. What remains visible to network observers is the destination IP address and the server hostname in the TLS SNI extension sent during the ClientHello. ESNI/ECH (Encrypted Client Hello) further encrypts the SNI in newer deployments.
Common causes include expired or self-signed certificates that fail client validation, hostname mismatches between the certificate's Subject Alternative Names and the requested domain, TLS version mismatches (server requires TLS 1.2 but client only offers 1.3), and clock skew causing certificate validity checks to fail. HSTS preload list mismatches can also block connections.
The HTTPS handshake is the broader sequence including DNS and TCP setup, while the TLS handshake is specifically the cryptographic negotiation phase that occurs after TCP is established. The TLS Handshake diagram isolates the ClientHello → ServerHello → Certificate → Finished exchange in detail; the HTTPS Handshake shows how it fits into the full connection flow.
mermaid
sequenceDiagram participant Browser participant DNS as DNS Resolver participant Server Browser->>DNS: Resolve secure.example.com DNS-->>Browser: IP: 203.0.113.55 note">Note over Browser,Server: TCP Handshake Browser->>Server: SYN Server-->>Browser: SYN-ACK Browser->>Server: ACK note">Note over Browser,Server: TLS 1.3 Handshake Browser->>Server: ClientHello (TLS 1.3, cipher suites, key share) Server-->>Browser: ServerHello (selected cipher, key share) Server-->>Browser: Certificate + CertificateVerify Server-->>Browser: Finished note">Note over Browser: Validate certificate chain\nagainst trusted CAs Browser->>Server: Finished (encrypted) note">Note over Browser,Server: Encrypted HTTP Exchange Browser->>Server: GET /dashboard HTTP/1.1 [encrypted] Server-->>Browser: HTTP/1.1 200 OK + HTML body [encrypted] note">Note over Browser,Server: Subsequent requests reuse TLS session
Copied to clipboard