What Happens in the 100 Milliseconds Between Clicking a Link and Seeing a Page: The TLS Handshake Deconstructed

The padlock icon in your browser’s address bar suggests something simple: this connection is secure. But in the roughly 100 milliseconds between clicking a link and seeing the page, your browser and the server performed one of the most sophisticated cryptographic dances in computing history. They established a shared secret over a public network, verified each other’s identities, and set up encrypted communication—all while an attacker watching every packet could learn nothing useful.

This process, the TLS handshake, is so routine that billions of people perform it daily without a second thought. Yet beneath the surface lies a remarkable convergence of cryptography, distributed trust, and protocol engineering. Understanding how it works reveals both why HTTPS matters and, equally important, what it doesn’t protect you from.

The Problem That Started Everything

In 1994, Netscape faced a business problem. They wanted people to buy things online, but nobody would transmit credit card numbers over a network where any intermediary could read the traffic. The solution needed to achieve something that seemed impossible: two strangers (your browser and a web server) needed to agree on a secret encryption key while everyone on the network watched, and they needed to verify each other’s identities without ever having met.

The result was SSL (Secure Sockets Layer), which evolved into TLS (Transport Layer Security). The fundamental challenge remains unchanged: how do you establish secure communication over an insecure channel?

The Three Problems Any Secure Protocol Must Solve

Every secure communication protocol must address three distinct problems:

Confidentiality: Only the intended recipients should be able to read the message. In TLS, this means encrypting all application data with symmetric encryption like AES-GCM or ChaCha20-Poly1305.

Integrity: The recipient must detect if anyone tampered with the message during transit. TLS uses authenticated encryption (AEAD) that combines encryption and integrity verification.

Authentication: You must verify you’re talking to the right party. Without this, an attacker could impersonate your bank, and encryption would only protect your secrets from everyone except the attacker.

The handshake’s job is to solve all three problems before any application data is exchanged. TLS 1.3, published as RFC 8446 in August 2018, accomplishes this in a single round trip—a significant improvement over the two round trips required by TLS 1.2.

The Modern TLS 1.3 Handshake

Let’s trace through what actually happens when your browser connects to an HTTPS server. We’ll follow a real TLS 1.3 connection, examining each message and the cryptographic operations they trigger.

Step 1: Client Hello—Guessing the Future

The handshake begins with your browser sending a ClientHello message. This isn’t just an introduction; it’s a bet on what the server will accept.

ClientHello:
  - TLS version: 1.3
  - Random: 32 bytes of random data
  - Cipher suites: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256
  - Key share: X25519 public key for key exchange
  - Server Name Indication: "example.com"
  - Supported versions: [1.3, 1.2]
  - Signature algorithms: rsa_pss_rsae_sha256, ecdsa_secp256r1_sha256, ...
  - ALPN: ["h2", "http/1.1"]

The critical innovation in TLS 1.3 is the key_share extension. Instead of waiting to learn what the server supports before generating a key share, the client guesses and includes a key share immediately. If the server accepts the guess, an entire round trip is saved.

The key share contains the client’s ephemeral public key for Elliptic Curve Diffie-Hellman (ECDHE) key exchange. This is typically an X25519 public key—32 bytes representing a point on Curve25519. The client also generates a corresponding private key, which it keeps secret.

Why X25519? The curve offers 128 bits of security with just 32-byte keys, compared to RSA which would need 3072-bit keys for equivalent security. More importantly, X25519 was designed to be resistant to implementation errors that have compromised other curves.

Step 2: Server Hello—Agreement and Immediate Key Derivation

The server responds with a ServerHello that accepts (or rejects) the client’s proposals:

ServerHello:
  - TLS version: 1.3
  - Random: 32 bytes of random data
  - Cipher suite: TLS_AES_256_GCM_SHA384
  - Key share: Server's X25519 public key

At this point, both sides can compute the shared secret. The client multiplies its private key by the server’s public key; the server multiplies its private key by the client’s public key. Due to the mathematics of elliptic curves, both operations yield the same result.

sequenceDiagram
    participant C as Client
    participant S as Server
    participant N as Network (Attacker)
    
    Note over C: Generate ephemeral key pair
    Note over C: private_key_c, public_key_c
    C->>S: ClientHello + public_key_c
    N->>N: Sees public_key_c (useless without private_key_c)
    
    Note over S: Generate ephemeral key pair
    Note over S: private_key_s, public_key_s
    S->>C: ServerHello + public_key_s
    N->>N: Sees public_key_s (useless without private_key_s)
    
    Note over C: shared = private_key_c × public_key_s
    Note over S: shared = private_key_s × public_key_c
    Note over C,S: Both compute same shared secret!

The shared secret is not the encryption key. Instead, it feeds into HKDF (HMAC-based Key Derivation Function), which derives multiple keys from this single secret. TLS 1.3 uses HKDF-Extract and HKDF-Expand operations to create:

• Client handshake key/IV for encrypting handshake messages
• Server handshake key/IV for encrypting handshake messages
• Later, application traffic keys for actual data

The key derivation follows a “traffic secret” model. Each phase of the handshake has its own secret, from which keys are derived. This provides clean separation and enables properties like forward secrecy.

Step 3: Encrypted Server Certificate and Authentication

Here’s where TLS 1.3 differs fundamentally from its predecessors. In TLS 1.2, the server’s certificate was sent in plaintext—an observer could see which certificate a client was requesting. In TLS 1.3, the certificate is encrypted using the handshake keys just derived.

The server sends:

EncryptedExtensions (encrypted):
  - Supported ALPN protocol: "h2"
  
Certificate (encrypted):
  - Server certificate chain
  
CertificateVerify (encrypted):
  - Signature over handshake transcript using server's private key
  
Finished (encrypted):
  - Verify_data confirming handshake integrity

The certificate chain typically consists of:

1. Leaf certificate: Contains the server’s domain name and public key
2. Intermediate certificate(s): Signed by a higher authority
3. Root certificate: Not sent (browsers have these pre-installed)

The CertificateVerify message is crucial for authentication. The server signs the entire handshake transcript—all messages exchanged so far—with its private key. This proves the server controls the private key corresponding to the certificate’s public key, and it binds the certificate to this specific handshake session, preventing replay attacks.

Step 4: Certificate Validation—The Trust Chain

Your browser now validates the server’s certificate. This involves several checks:

Chain Building: The browser constructs a path from the leaf certificate to a trusted root. Each certificate in the chain must be signed by the certificate above it.

flowchart TB
    subgraph "Certificate Chain of Trust"
        LC[Leaf Certificate<br/>example.com<br/>Signed by Intermediate CA]
        IC[Intermediate CA Certificate<br/>Signed by Root CA]
        RC[Root CA Certificate<br/>Self-signed<br/>Pre-installed in Browser]
    end
    
    LC --> IC --> RC
    
    style LC fill:#e8f5e9
    style IC fill:#fff3e0
    style RC fill:#e3f2fd

Signature Verification: Each signature in the chain is cryptographically verified. The signature algorithm (RSA-PSS, ECDSA) and hash function (SHA-256, SHA-384) are checked against the certificate’s signatureAlgorithm field.

Validity Period: The current time must fall within the certificate’s notBefore and notAfter dates. Expired or not-yet-valid certificates are rejected.

Revocation Check: Has the certificate been revoked? Browsers use several mechanisms:

• OCSP (Online Certificate Status Protocol): Query the CA in real-time
• OCSP Stapling: Server provides a recent OCSP response signed by the CA
• CRL (Certificate Revocation List): Download list of revoked certificates

Certificate Transparency: Modern browsers require certificates to be logged in CT logs—public, append-only ledgers of all issued certificates. This prevents CAs from issuing certificates without detection. The server must provide Signed Certificate Timestamps (SCTs) proving the certificate was logged.

If any check fails, your browser shows a warning. The user can proceed, but they’re explicitly informed that something is wrong.

Step 5: Client Finished—Mutual Confirmation

The client sends its own Finished message, encrypted with the handshake keys:

Finished (encrypted):
  - Verify_data computed over handshake transcript

This message proves the client received and processed the server’s messages correctly. At this point, both sides compute the application traffic keys using the complete handshake transcript as input to HKDF.

Step 6: Application Data

Finally, actual HTTP requests and responses flow over the encrypted connection. Each record is encrypted with the application traffic keys using the negotiated AEAD cipher (AES-GCM, AES-CCM, or ChaCha20-Poly1305).

flowchart TB
    subgraph "TLS 1.3 Key Derivation"
        ECDHE[ECDHE Shared Secret] --> HS[Handshake Secret]
        HS --> CHK[Client Handshake Keys]
        HS --> SHK[Server Handshake Keys]
        HS --> MS[Master Secret]
        MS --> CAT[Client Application Traffic]
        MS --> SAT[Server Application Traffic]
        CAT --> CAK[Client App Keys]
        SAT --> SAK[Server App Keys]
    end
    
    style ECDHE fill:#e1f5fe
    style HS fill:#fff3e0
    style MS fill:#f3e5f5
    style CAK fill:#e8f5e9
    style SAK fill:#e8f5e9

Perfect Forward Secrecy: Why the Past Stays Secret

One of TLS 1.3’s most important properties is perfect forward secrecy (PFS). Even if an attacker records all your encrypted traffic today and later steals the server’s private key, they cannot decrypt the recorded traffic.

This works because the encryption keys derive from the ECDHE key exchange, which uses ephemeral key pairs generated fresh for each session. The server’s long-term private key only authenticates the handshake (via CertificateVerify), not encrypt the session.

Without PFS, compromising a server’s private key would reveal every session ever conducted with that server—a catastrophic failure mode. The 2013 revelations about NSA recording encrypted traffic made PFS not just a good practice but an essential requirement.

Session Resumption: Trading Security for Speed

A full TLS 1.3 handshake requires one round trip (plus the TCP handshake’s round trip). For a client in New York connecting to a server in Singapore, that’s potentially 200ms just to establish the secure connection—before any HTTP is exchanged.

Session resumption addresses this by reusing cryptographic state from a previous connection.

Pre-Shared Key (PSK) Resumption

After the handshake, the server can send a “session ticket” to the client. This ticket contains encrypted session state (the resumption secret) that only the server can decrypt. When reconnecting, the client includes this ticket in its ClientHello.

sequenceDiagram
    participant C as Client
    participant S as Server
    
    Note over C,S: Initial Connection
    C->>S: ClientHello + Key Share
    S->>C: ServerHello + Key Share + Certificate + Finished
    C->>S: Finished
    S->>C: NewSessionTicket (encrypted resumption secret)
    Note over C: Store ticket
    
    Note over C,S: Later - Resumed Connection
    C->>S: ClientHello + PSK + Key Share
    Note over S: Decrypt ticket, verify PSK
    S->>C: ServerHello + Accept PSK
    Note over C,S: Application data immediately!

If the server accepts the PSK, application data can flow immediately—zero round trips for the TLS handshake. This is “0-RTT” resumption.

The 0-RTT Trade-off

0-RTT sounds perfect, but it has a security cost. The client sends application data before the server authenticates. This creates vulnerabilities:

• Replay attacks: An attacker can capture and replay 0-RTT data
• No forward secrecy: The resumption secret is used directly

TLS 1.3 allows servers to reject 0-RTT data or limit it to idempotent operations (GET requests without side effects). The specification recommends that applications implement their own replay protection for 0-RTT data.

What HTTPS Does NOT Protect Against

Understanding TLS requires understanding its limits. The padlock icon doesn’t mean “safe”—it means “encrypted in transit.”

Content Safety

TLS encrypts the connection, not the content. A malicious site can have a perfectly valid certificate and encrypted connection. The padlock indicates authenticity (you’re talking to who you think you’re talking to), not benevolence.

Endpoint Security

TLS protects data in transit between endpoints. It does nothing for data at rest on the server or client. If a server is compromised, all data stored there is exposed, regardless of how securely it was transmitted.

Metadata Leakage

While TLS encrypts the application data, significant metadata remains visible:

• Server Name Indication (SNI): The hostname is sent in plaintext during ClientHello. An observer can see which sites you visit, even if they can’t see the content.
• Traffic analysis: The size and timing of encrypted packets can reveal information about the content.
• DNS queries: Before TLS begins, your device must resolve the hostname.

Encrypted Client Hello (ECH) is a newer extension that encrypts the SNI and other sensitive handshake data. However, it requires the server to publish a public key via DNS, and adoption is still limited.

Downgrade Attacks

TLS protects against downgrade attacks through its version negotiation. A network attacker cannot force a TLS 1.3 connection to use TLS 1.2, as the version is cryptographically bound to the handshake transcript. But if the server only supports TLS 1.2, the connection will use that older protocol.

The Evolution From SSL to TLS 1.3

The protocols we use today emerged from decades of attacks and improvements.

Each protocol version emerged in response to discovered vulnerabilities. POODLE exploited SSL 3.0’s padding scheme. BEAST attacked TLS 1.0’s predictable IVs. Lucky13 exploited timing variations in CBC mode decryption.

TLS 1.3 removed all the problematic features: RSA key transport (no forward secrecy), CBC mode ciphers (padding oracle attacks), RC4 (broken stream cipher), MD5 and SHA-1 (collision vulnerabilities), compression (CRIME/BREACH attacks), and renegotiation (renegotiation attack).

The result is a protocol that’s simultaneously more secure and simpler. TLS 1.3 has five cipher suites (all AEAD), compared to TLS 1.2’s dozens (including many now-weak options).

Performance Implications

The cryptographic operations in TLS have real costs.

Handshake Latency

Studies measuring TLS handshake latency across 891 hosting providers found:

• TLS 1.2 average handshake: 89-116ms depending on region
• TLS 1.3 average handshake: 30-50% faster due to reduced round trips

The improvement is most dramatic over high-latency connections. A TLS 1.2 handshake to a server 200ms away takes at least 400ms (two round trips). TLS 1.3 takes 200ms (one round trip).

CPU Cost

The most expensive operations are:

1. ECDHE key exchange: X25519 key generation and shared secret computation
2. Certificate signature verification: RSA-2048 or ECDSA signature verification
3. Symmetric encryption: AES-GCM or ChaCha20-Poly1305

For servers handling many connections, the handshake cost is significant. Using ECDSA certificates instead of RSA reduces signature verification time by approximately 40%. Hardware acceleration for AES (AES-NI instructions) makes AES-GCM the fastest option on systems that support it; on systems without, ChaCha20-Poly1305 is faster.

Connection Reuse

HTTP/2 multiplexes multiple streams over a single TLS connection, amortizing handshake costs over many requests. HTTP/3, built on QUIC, integrates TLS 1.3 directly into the transport protocol, further reducing overhead.

The Trust Infrastructure: Certificate Authorities

TLS’s security model depends on Certificate Authorities (CAs)—organizations trusted to verify domain ownership before issuing certificates.

Your browser or operating system comes with a root store containing about 150 root certificates. These roots can issue certificates directly or delegate to intermediate CAs. The entire system relies on these CAs acting correctly.

When CAs fail, the consequences are severe. DigiNotar, a Dutch CA, was compromised in 2011 and attackers issued fraudulent certificates for Google, Yahoo, and other major sites. The company went bankrupt within weeks, and major browsers removed DigiNotar roots from their stores.

Certificate Transparency (CT), now required by all major browsers, addresses this by making certificate issuance publicly auditable. Every certificate must be logged in multiple CT logs, creating an immutable record. Domain owners can monitor these logs for unexpected certificates.

Practical Considerations

Why Certificates Expire

Certificates have maximum validity periods (currently 398 days, reduced from 825 days in 2020). This ensures that:

1. Cryptographic weaknesses are eventually phased out
2. Stolen private keys have limited usefulness
3. Certificate information (domain ownership, organization details) remains current

Certificate Types

Different validation levels provide different assurances:

• Domain Validation (DV): CA verifies domain control (usually via email or DNS)
• Organization Validation (OV): CA verifies organization identity
• Extended Validation (EV): CA performs extensive verification, browser shows organization name (in older browsers)

Notably, from a cryptographic perspective, all certificate types provide identical security. The difference is in the identity claims being certified.

ACME and Automated Certificates

Let’s Encrypt, launched in 2015, automated certificate issuance using the ACME protocol. The process works as follows:

1. Client requests certificate for a domain
2. CA challenges the client to prove domain control (HTTP file, DNS record, or TLS certificate)
3. Client completes challenge
4. CA issues certificate, logs to CT, delivers to client
5. Client automatically renews before expiration

This automation has driven HTTPS adoption from under 40% of web traffic in 2015 to over 95% today. The Let’s Encrypt root is trusted by all major browsers.

Looking Forward

TLS continues to evolve. Current developments include:

Post-Quantum TLS: NIST has standardized quantum-resistant algorithms (ML-KEM, ML-DSA), and implementations are beginning to appear. The challenge is balancing security with performance—post-quantum keys and signatures are significantly larger.

Encrypted Client Hello (ECH): This extension encrypts the entire ClientHello, including SNI, addressing a major privacy gap. Deployment requires server operators to publish public keys via DNS.

Delegated Credentials: Allows servers to delegate signing authority to short-lived credentials, reducing the impact of server key compromise.

The fundamental tension in protocol design remains: security versus performance versus deployability. TLS 1.3 made significant progress by removing legacy features that complicated implementation without providing meaningful security. Future versions will face similar choices as new attacks emerge and computing environments change.

The Bottom Line

The TLS handshake solves a genuinely hard problem: establishing secure communication between parties who have never met, over a network controlled by adversaries. That it does so in roughly 100 milliseconds, using only a few kilobytes of data, is a remarkable engineering achievement.

But TLS is not magic. It protects against specific threats (eavesdropping, tampering, impersonation) while leaving others (malicious endpoints, metadata analysis, application vulnerabilities) untouched. The padlock icon indicates a secure channel, not a safe destination.

Understanding what happens in those 100 milliseconds—the key exchange, the certificate validation, the derivation of session keys—reveals both the sophistication of the protocol and the boundaries of its protection. And that understanding is the first step toward using HTTPS effectively, whether as a developer implementing it or as a user trusting it.

References

1. Rescorla, E. (2018). RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3. IETF. https://datatracker.ietf.org/doc/html/rfc8446

2. Krawczyk, H., & Eronen, P. (2010). RFC 5869: HMAC-based Extract-and-Expand Key Derivation Function (HKDF). IETF. https://datatracker.ietf.org/doc/html/rfc5869

3. Langley, A., & Chang, W. (2016). ChaCha20 and Poly1305 for IETF Protocols. RFC 8439. IETF. https://datatracker.ietf.org/doc/html/rfc8439

4. Jivsov, A. (2015). Elliptic Curve Cryptography (ECC) in OpenPGP. RFC 6637. IETF. https://datatracker.ietf.org/doc/html/rfc6637

5. Laurie, B., Langley, A., & Kasper, E. (2013). RFC 6962: Certificate Transparency. IETF. https://datatracker.ietf.org/doc/html/rfc6962

6. Barnes, R., et al. (2015). RFC 7525: Recommendations for Secure Use of TLS and DTLS. IETF. https://datatracker.ietf.org/doc/html/rfc7525

7. The Illustrated TLS 1.3 Connection. https://tls13.xargs.org/

8. Cloudflare. (2018). A Detailed Look at RFC 8446 (a.k.a. TLS 1.3). https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/

9. Cloudflare. (2017). Introducing Zero Round Trip Time Resumption (0-RTT). https://blog.cloudflare.com/introducing-0-rtt/

10. Cloudflare. (2016). It takes two to ChaCha (Poly). https://blog.cloudflare.com/it-takes-two-to-chacha-poly/

11. DigiCert. (2023). How Certificate Chains Work. https://knowledge.digicert.com/solution/how-certificate-chains-work

12. Let’s Encrypt. (2025). How It Works. https://letsencrypt.org/how-it-works/

13. Keyfactor. (2020). What is the Certificate Chain of Trust? https://www.keyfactor.com/blog/certificate-chain-of-trust/

14. Smallstep. (2025). Everything you should know about certificates and PKI but are too afraid to ask. https://smallstep.com/blog/everything-pki/

15. The SSL Store. (2020). Perfect Forward Secrecy Explained. https://www.thesslstore.com/blog/perfect-forward-secrecy-explained/

16. The SSL Store. (2018). TLS 1.3 Handshake: Taking a Closer Look. https://www.thesslstore.com/blog/tls-1-3-handshake-tls-1-2/

17. Cloudflare. (2015). TLS Session Resumption: Full-speed and Secure. https://blog.cloudflare.com/tls-session-resumption-full-speed-and-secure/

18. Wikipedia. Server Name Indication. https://en.wikipedia.org/wiki/Server_Name_Indication

19. Wikipedia. Certificate Transparency. https://en.wikipedia.org/wiki/Certificate_Transparency

20. Trail of Bits. (2019). What Application Developers Need To Know About TLS Early Data (0-RTT). https://blog.trailofbits.com/2019/03/25/what-application-developers-need-to-know-about-tls-early-data-0rtt/

21. Cloudflare. (2013). A (Relatively Easy To Understand) Primer on Elliptic Curve Cryptography. https://blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/

22. Wikipedia. HTTP Strict Transport Security. https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

23. MDN Web Docs. Strict-Transport-Security. https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Strict-Transport-Security

24. OWASP. HTTP Strict Transport Security Cheat Sheet. https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html

25. Auth0. (2023). The TLS Handshake Explained. https://auth0.com/blog/the-tls-handshake-explained/

26. WPTR. (2026). A Quantitative Analysis of SSL/TLS Handshake Latency. https://www.wptr.net/blog/ssl-tls-handshake-latency-analysis

27. Catchpoint. TLS 1.2 vs. 1.3—Handshake, Performance, and Other Improvements. https://www.catchpoint.com/http2-vs-http3/tls1-2-vs-1-3

28. Wikipedia. Encrypted Client Hello. https://en.wikipedia.org/wiki/Server_Name_Indication#Encrypted_Client_Hello

29. IETF. (2024). TLS Encrypted Client Hello. draft-ietf-tls-esni-18. https://www.ietf.org/archive/id/draft-ietf-tls-esni-18.html

30. DigiCert. (2016). Debunking SSL and HTTPS Security Myths. https://www.digicert.com/blog/debunking-ssl-and-https-security-myths

31. Wikipedia. HTTP Public Key Pinning. https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning

32. OWASP. Certificate and Public Key Pinning. https://owasp.org/www-community/controls/Certificate_and_Public_Key_Pinning

33. SSL.com. (2024). Comparing ECDSA vs RSA: A Simple Guide. https://www.ssl.com/article/comparing-ecdsa-vs-rsa-a-simple-guide/

34. Wikipedia. ChaCha20-Poly1305. https://en.wikipedia.org/wiki/ChaCha20-Poly1305

35. KeyCDN. (2023). ALPN Explained. https://www.keycdn.com/support/alpn

36. Wikipedia. Application-Layer Protocol Negotiation. https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation

37. Smallstep. (2025). OCSP vs CRL Explained. https://smallstep.com/blog/ocsp-vs-crl-explained/

38. Cloudflare. (2017). High-reliability OCSP stapling and why it matters. https://blog.cloudflare.com/high-reliability-ocsp-stapling/

39. Let’s Encrypt. (2025). Certificate Transparency (CT) Logs. https://letsencrypt.org/docs/ct-logs/

40. Cloudflare. What is encrypted SNI? https://www.cloudflare.com/learning/ssl/what-is-encrypted-sni/