SSL/TLS Handshake Process

The SSL/TLS handshake is a negotiation process where client and server establish a secure, encrypted connection before exchanging application data. The handshake verifies server identity through certificate validation, negotiates encryption algorithms (cipher suites), performs cryptographic key exchange, and derives session keys for symmetric encryption. This process occurs after TCP handshake for every HTTPS connection.

TLS (Transport Layer Security), the successor to SSL (Secure Sockets Layer), protects HTTP, SMTP, FTP, and other protocols. TLS 1.2 (RFC 5246, 2008) and TLS 1.3 (RFC 8446, 2018) are the current versions. TLS 1.3 reduces handshake latency from 2 RTT to 1 RTT, improves security by removing obsolete features, and encrypts more of the handshake metadata.

The handshake must complete before application data flows. For HTTPS, this means TCP handshake (1.5 RTT) + TLS handshake (1-2 RTT) = 2.5-3.5 RTT before HTTP request sends. TLS 1.3’s 1-RTT handshake reduces this to 2.5 RTT total. Session resumption and TLS False Start further reduce latency for returning clients.

Last updated: 2026-04-22

How TLS Handshake Works

The handshake establishes shared secrets for encryption without transmitting those secrets over the network. Public key cryptography enables secure key exchange; symmetric cryptography provides efficient data encryption after handshake.

TLS 1.2 Handshake (2 RTT)

Step 1: ClientHello

Client sends:

• TLS version supported (e.g., TLS 1.2)
• Client random (32 bytes: timestamp + random data)
• Cipher suites supported (list of algorithm combinations)
• Compression methods (typically null)
• TLS extensions: Server Name Indication (SNI), supported groups (ECDHE curves), signature algorithms, session ID for resumption

Step 2: ServerHello

Server responds with:

• Selected TLS version
• Server random (32 bytes)
• Selected cipher suite from client’s list
• Selected compression method (usually null)
• Server certificate (X.509 certificate chain)
• ServerKeyExchange (for DHE/ECDHE cipher suites; contains Diffie-Hellman parameters)
• CertificateRequest (optional, if server requires client certificate)
• ServerHelloDone

Step 3: Client Key Exchange and Verification

Client:

• Validates server certificate (signature, expiration, CA trust chain, hostname match)
• Verifies ServerKeyExchange signature (if present)
• Generates pre-master secret (for RSA key exchange) or performs Diffie-Hellman calculation (for DHE/ECDHE)
• Sends ClientKeyExchange message containing encrypted pre-master secret (RSA) or DH public value (DHE/ECDHE)
• Optional: Sends Certificate and CertificateVerify if server requested client certificate
• Sends ChangeCipherSpec to signal encrypted records follow
• Sends Finished message (encrypted with new keys, verifies handshake integrity)

Step 4: Server Finish

Server:

• Decrypts pre-master secret (RSA) or performs Diffie-Hellman calculation (DHE/ECDHE)
• Derives master secret from pre-master secret, client random, server random
• Derives session keys from master secret: client/server MAC keys, client/server encryption keys, client/server IVs
• Sends ChangeCipherSpec
• Sends Finished message (encrypted, verified by client)

Handshake complete. Application data encrypted with derived session keys.

TLS 1.3 Handshake (1 RTT)

TLS 1.3 simplifies and secures the handshake:

Step 1: ClientHello

Client sends:

• TLS version 1.3
• Client random
• Cipher suites (AEAD-only: AES-GCM, ChaCha20-Poly1305)
• Key share extension: ECDHE public value (guessing server’s preferred curve)
• Supported signature algorithms
• SNI, supported versions extension

Step 2: ServerHello, EncryptedExtensions, Certificate, Finished

Server responds in single flight:

• ServerHello: selected cipher suite, server random
• Key share extension: server’s ECDHE public value
• EncryptedExtensions: SNI response, other non-crypto extensions
• Certificate: server certificate chain (encrypted)
• CertificateVerify: signature over handshake transcript (encrypted)
• Finished: MAC over handshake transcript (encrypted)

All messages after ServerHello encrypted with keys derived from ECDHE shared secret. Certificate details hidden from passive observers.

Step 3: Client Finished

Client:

• Validates server certificate
• Verifies CertificateVerify signature
• Sends Finished message (encrypted)

Handshake complete in 1 RTT. Forward secrecy established (ECDHE mandatory). Legacy algorithms removed (RSA key exchange, CBC mode, MD5, SHA-1, compression).

Key Exchange Methods

RSA Key Exchange (TLS 1.2, Removed in TLS 1.3)

Client generates pre-master secret, encrypts with server’s RSA public key from certificate. Server decrypts with private key. No forward secrecy: if server’s private key compromised, all past sessions decryptable. Removed from TLS 1.3 due to lack of forward secrecy.

Diffie-Hellman (DHE) Key Exchange

Both sides generate DH key pairs, exchange public values. Shared secret computed without transmitting it. Forward secrecy: server’s RSA key only signs DH parameters, doesn’t encrypt pre-master secret. Private key compromise doesn’t reveal past session keys. Slow (large prime arithmetic).

Elliptic Curve Diffie-Hellman (ECDHE)

Same as DHE but using elliptic curve cryptography. Smaller keys, faster computation. Most common key exchange in TLS 1.2 and TLS 1.3. Curves: X25519 (preferred), secp256r1 (P-256), secp384r1 (P-384). Forward secrecy. Required in TLS 1.3.

Cipher Suites

A cipher suite specifies algorithms for key exchange, authentication, encryption, and MAC. Named as: TLS_KEYEXCHANGE_AUTHENTICATION_WITH_CIPHER_MODE_MAC.

Example cipher suites:

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (TLS 1.2)
  • Key exchange: ECDHE
  • Authentication: RSA (certificate signature)
  • Encryption: AES-128 in GCM mode (authenticated encryption)
  • MAC: SHA256 (used in GCM’s authentication)
• TLS_AES_256_GCM_SHA384 (TLS 1.3)
  • Encryption: AES-256-GCM
  • Hash: SHA384
  • Key exchange: ECDHE (implied, only option in TLS 1.3)

TLS 1.3 cipher suites only specify symmetric algorithms; key exchange always ECDHE. TLS 1.2 cipher suites specify all components.

Certificate Validation

Client validates server certificate during handshake:

Chain Validation

• Certificate signed by trusted Certificate Authority (CA)
• CA certificate signed by root CA (built into OS/browser trust store)
• Entire chain verified from server cert to root CA
• No revoked certificates (checked via CRL or OCSP)

Certificate Properties

• Current time within certificate validity period (not before/not after dates)
• Certificate not revoked (CRL or OCSP check)
• Hostname matches certificate Subject Alternative Name (SAN) or Common Name (CN)
• Certificate has proper key usage: digitalSignature for ECDHE, keyEncipherment for RSA key exchange
• Extended Key Usage includes TLS Web Server Authentication

Weakness Detection

• Minimum key size: RSA ≥2048 bits, ECDSA ≥256 bits
• Signature algorithm: SHA-256 or stronger (reject SHA-1, MD5)
• Certificate not weak (e.g., Debian weak key vulnerability)

If any check fails, client aborts handshake with certificate error.

Session Resumption

Avoid full handshake for returning clients:

Session IDs (TLS 1.2)

Server provides session ID in ServerHello. Client reconnects with session ID in ClientHello. Server looks up session, resumes with abbreviated handshake (1 RTT). Session state stored on server (memory or distributed cache). Limited scalability.

Session Tickets (TLS 1.2)

Server encrypts session state into ticket, sends to client after handshake. Client presents ticket in next connection. Server decrypts ticket, resumes session. Stateless on server, scalable. Ticket key rotation required for forward secrecy.

Pre-Shared Key (PSK) (TLS 1.3)

TLS 1.3 unifies resumption under PSK. Client sends PSK identity in ClientHello. Server accepts PSK, derives keys faster. Can combine with ECDHE for forward secrecy (PSK + fresh ECDHE). Supports external PSK provisioning.

0-RTT Data (TLS 1.3)

Client sends application data in first flight with PSK. Eliminates handshake latency entirely for known clients. Data replayable (no server state when sent). Use only for idempotent requests (GET requests, not POST). Server may reject 0-RTT, requiring fallback to 1-RTT handshake.

TLS 1.2 vs TLS 1.3 Handshake Comparison

TLS 1.3 improves security by removing vulnerable algorithms, reduces latency through 1-RTT handshake, and enhances privacy by encrypting certificates.

When TLS Handshake Occurs

TLS handshake occurs when:

• Browser connects to HTTPS website
• API client calls HTTPS endpoint
• Email client sends via SMTPS or receives via IMAPS/POP3S
• SSH client uses certificate-based authentication (not same protocol, but similar concepts)
• Any TCP connection upgrades to TLS (STARTTLS for SMTP, IMAP)

TLS handshake does NOT occur when:

• HTTP connection (unencrypted, no TLS)
• Connection already established (persistent HTTPS connections reuse TLS session)
• Session resumption succeeds (abbreviated handshake)
• Application uses plaintext protocol

Signals of Handshake Issues

• Certificate errors: Expired, wrong hostname, untrusted CA
• Cipher suite mismatch: Client and server share no common algorithms
• Protocol version mismatch: Client only supports TLS 1.3, server only TLS 1.0
• Handshake timeout: Network drops ClientHello or ServerHello
• Weak cryptography warnings: SHA-1 certificates, small RSA keys, outdated ciphers
• Performance degradation: Full handshake on every request (no session resumption)

Metrics and Measurement

Handshake Performance Metrics:

• TLS handshake time: Time from ClientHello to Finished (target: <100ms local, <200ms regional)
• Certificate validation time: Time to verify certificate chain (target: <50ms)
• Key exchange time: Time for ECDHE computation (target: <10ms)
• Total connection setup: TCP + TLS handshake (target: <300ms global)

Security Metrics:

• TLS version distribution: Percentage of TLS 1.3 vs TLS 1.2 connections (target: maximize TLS 1.3)
• Cipher suite strength: Percentage of connections with forward secrecy (target: 100%)
• Certificate validity: Days until expiration, proper hostname matching
• OCSP/CRL check latency: Time to verify certificate revocation (target: <50ms)

According to SSL Labs (2024), 78% of websites support TLS 1.3. Average TLS handshake time for well-configured servers: 20-80ms. Poorly configured servers (small DH groups, excessive certificate chain depth) see 200-500ms handshake times.

Real-World Use Cases

E-Commerce Websites

• HTTPS for all pages (protects login, payment data)
• EV certificates display company name in browser
• Session resumption for fast repeated connections
• HSTS header forces HTTPS, prevents downgrade attacks
• Certificate pinning for mobile apps

APIs and Microservices

• Mutual TLS (mTLS): Client and server authenticate with certificates
• Short-lived certificates via certificate automation
• Service mesh issues and renews certificates automatically
• API gateway terminates TLS, forwards to backend services
• Certificate rotation without service restart

Content Delivery Networks

• TLS termination at edge locations (closer to users, reduces RTT)
• Shared TLS infrastructure across customers
• Session tickets for stateless resumption across edge servers
• OCSP stapling reduces certificate validation latency
• Automatic certificate provisioning (Let’s Encrypt integration)

Mobile Applications

• TLS 1.3 for faster handshakes on high-latency mobile networks
• Certificate pinning prevents MITM with compromised CA
• Session resumption critical for battery life
• 0-RTT for instant data fetch (with idempotency guarantees)

Enterprise Applications

• Internal CA issues certificates for internal services
• Certificate-based authentication for zero-trust architectures
• TLS inspection by security appliances (break-and-inspect)
• mTLS for service-to-service communication

Common Mistakes and Fixes

Mistake: Using RSA key exchange (no forward secrecy) in TLS 1.2 Fix: Configure server to prioritize ECDHE cipher suites over RSA. Forward secrecy protects past sessions if private key compromised. Modern clients support ECDHE; prioritize TLS_ECDHE_* cipher suites. Transition to TLS 1.3 where forward secrecy is mandatory.

Mistake: Not enabling session resumption Fix: Enable session tickets for stateless resumption (scales better than session IDs). Configure ticket key rotation (every 6-24 hours) for forward secrecy of resumed sessions. TLS 1.3 uses PSK-based resumption; ensure server supports. Monitor resumption hit rate.

Mistake: Sending excessive certificate chain depth Fix: Send only necessary intermediate certificates (typically 1-2 intermediates). Root CA already trusted by client; don’t send root. Large chains increase handshake size, latency, and validation time. Test with SSL Labs to verify chain completeness without redundancy.

Mistake: Using weak or outdated cipher suites Fix: Disable cipher suites with known vulnerabilities: RC4, 3DES, CBC mode with non-authenticated encryption, SHA-1. Prefer AEAD ciphers (AES-GCM, ChaCha20-Poly1305). Configure server to enforce strong cipher suite ordering. Update TLS libraries to latest versions.

Mistake: Not implementing OCSP stapling Fix: Enable OCSP stapling to reduce certificate validation latency. Server staples OCSP response to certificate, eliminating client’s OCSP lookup. Reduces handshake time by 50-200ms. Prevents privacy leak of client querying OCSP responder. Most modern servers support stapling.

Mistake: Ignoring TLS 1.3 adoption Fix: Enable TLS 1.3 for 1-RTT handshake, improved security, and simplified configuration. All modern browsers support TLS 1.3 (Chrome, Firefox, Safari, Edge). Monitor TLS version statistics. TLS 1.3’s design eliminates entire classes of vulnerabilities.

Frequently Asked Questions

What is the difference between SSL and TLS? SSL (Secure Sockets Layer) was the original protocol developed by Netscape (SSL 1.0, 2.0, 3.0). TLS (Transport Layer Security) is the IETF standard successor (TLS 1.0, 1.1, 1.2, 1.3). SSL has known vulnerabilities; all versions deprecated. TLS is the current standard. Colloquially, “SSL certificate” refers to X.509 certificates used in TLS.

Why does TLS handshake happen after TCP handshake? TLS operates over TCP, requiring a reliable transport. TCP establishes connection first (SYN, SYN-ACK, ACK), then TLS handshake runs over that connection. TLS records are transmitted in TCP segments. TCP provides reliability; TLS provides security. QUIC (HTTP/3) combines transport and TLS into single handshake, reducing total setup time.

How does the client know the server’s public key? Server sends its X.509 certificate in ServerHello message. Certificate contains server’s public key. Client validates certificate chain to trusted root CA. If valid, client trusts the public key in certificate. For ECDHE, server signs ServerKeyExchange with private key; client verifies signature with public key from certificate.

What happens if certificate validation fails? Client aborts handshake, displays error to user. Common errors: expired certificate, hostname mismatch, untrusted CA, self-signed certificate (not in trust store), revoked certificate. User may override warning (not recommended for production). Applications should fail closed, not allow proceeding with invalid certificate.

How does TLS 1.3 achieve 1-RTT handshake? TLS 1.3 client sends key share in ClientHello (guessing server’s preferred curve). Server immediately computes shared secret and sends encrypted response. Eliminates round trip from TLS 1.2 where client waited for ServerHello before sending key share. TLS 1.3 also encrypts certificate, reducing plaintext metadata.

What is forward secrecy and why does it matter? Forward secrecy means session keys cannot be derived from server’s private key. ECDHE generates ephemeral key pairs per session. Even if server’s private key compromised later, past sessions remain secure. Without forward secrecy (RSA key exchange), private key compromise decrypts all past sessions. Mandatory in TLS 1.3.

Can TLS handshake be intercepted? Active attacker with compromised CA certificate can intercept (man-in-the-middle). Certificate pinning prevents this by validating specific certificate or public key. Passive attackers cannot decrypt handshake due to key exchange cryptography. TLS 1.3 encrypts more of handshake, reducing metadata exposure to passive observers.

How This Applies in Practice

Understanding TLS handshake is essential for debugging HTTPS issues, optimizing performance, and implementing secure communications.

Performance Optimization:

• Enable TLS 1.3 for 1-RTT handshake
• Configure session tickets for resumption
• Use OCSP stapling to reduce certificate validation latency
• Optimize certificate chain (remove redundant intermediates)
• Enable TLS False Start for TLS 1.2 (send data before Finished)
• Terminate TLS at CDN edge for lower RTT

Security Hardening:

• Use strong cipher suites (AEAD, ECDHE, SHA-256+)
• Enable TLS 1.3, disable TLS 1.0 and 1.1
• Use certificates with 2048+ bit RSA or 256+ bit ECDSA
• Enable HSTS to force HTTPS
• Implement certificate pinning for mobile apps
• Monitor certificate expiration proactively

Troubleshooting Handshake Issues:

• Use openssl s_client to test handshake: openssl s_client -connect example.com:443
• Check cipher suite configuration with SSL Labs test
• Verify certificate chain completeness
• Monitor handshake latency and failure rates
• Check for mixed content (HTTP resources on HTTPS page)
• Test with different clients (browsers, curl, openssl)

TLS Handshake on Azion

Azion provides optimized TLS termination and management:

• TLS 1.3 support for fastest handshake performance
• Edge termination reduces RTT (users connect to nearby edge locations)
• Managed SSL certificates with automatic renewal
• OCSP stapling for reduced certificate validation latency
• Session ticket encryption across edge network for resumption
• HSTS configuration for HTTPS enforcement
• mTLS support for API authentication
• Digital Certificates management through Azion Console and API

Azion’s global network terminates TLS connections at edge locations worldwide, minimizing handshake latency for end users while maintaining strong security posture.

Learn more about Digital Certificates and mTLS vs TLS.

Sources

• Dierks, T., Rescorla, E. “RFC 5246: TLS 1.2.” IETF, 2008. https://tools.ietf.org/html/rfc5246
• Rescorla, E. “RFC 8446: TLS 1.3.” IETF, 2018. https://tools.ietf.org/html/rfc8446
• SSL Labs. “SSL Server Test.” https://www.ssllabs.com/ssltest/
• Rescorla, E. “The Transport Layer Security (TLS) Protocol Version 1.3.” IETF, 2018. https://www.rfc-editor.org/rfc/rfc8446