Every time you visit an HTTPS website, your browser and the server perform an intricate dance called the TLS handshake. It happens in milliseconds, completely invisible to you, but it's what makes secure communication possible. New to SSL/TLS? Check out our beginner's guide first. Let's peek behind the curtain.

What Is the TLS Handshake?

The TLS handshake is the process where your browser and a web server:

Agree on encryption methods - What algorithms to use
Verify identities - Is this really the server I want?
Exchange keys - Create shared secrets for encryption
Establish a secure channel - Start encrypted communication

All of this happens before any actual website data is transferred.

TLS 1.2 Handshake: Step by Step

Let's walk through the classic TLS 1.2 handshake:

Step 1: Client Hello

Your browser initiates the connection:

Client → Server:
- "Hello! I want to connect securely"
- TLS version I support (e.g., TLS 1.2)
- List of cipher suites I can use
- Random number (Client Random)
- Session ID (for resumption)
- Extensions (SNI, etc.)

What's SNI? Server Name Indication tells the server which domain you're trying to reach. This is crucial for servers hosting multiple sites on one IP address.

Step 2: Server Hello

The server responds with its choices:

Server → Client:
- "Hello back! Let's do this"
- TLS version we'll use
- Cipher suite selected
- Random number (Server Random)
- Session ID

Step 3: Server Certificate

The server sends its SSL certificate:

Server → Client:
- Server's certificate
- Intermediate certificates (certificate chain)

Your browser now:

Verifies the certificate is valid
Checks it's not expired
Confirms it's for the right domain
Validates the certificate chain to a trusted root

Step 4: Server Key Exchange (if needed)

For certain cipher suites (like those using Diffie-Hellman), the server sends additional key exchange parameters:

Server → Client:
- DH parameters
- Server's DH public value
- Signature of the above

Step 5: Server Hello Done

Server → Client:
- "I'm done with my part of the hello"

Step 6: Client Key Exchange

The client generates and sends key material:

Client → Server:
- Pre-master secret (encrypted with server's public key)
  OR
- Client's DH public value

At this point, both sides can compute the master secret using:

Client Random
Server Random
Pre-master secret

From the master secret, they derive:

Encryption keys
MAC keys
IVs (Initialization Vectors)

Step 7: Change Cipher Spec (Client)

Client → Server:
- "Switching to encrypted mode now"

Step 8: Client Finished

Client → Server (encrypted):
- Hash of all handshake messages
- "I'm done, here's proof we agree"

Step 9: Change Cipher Spec (Server)

Server → Client:
- "I'm switching to encrypted mode too"

Step 10: Server Finished

Server → Client (encrypted):
- Hash of all handshake messages
- "I'm done too, we're in sync"

Handshake Complete! 🎉

Both sides now have:

Agreed encryption algorithms
Shared secret keys
Verified each other (at least the server)

All subsequent communication is encrypted.

TLS 1.3 Handshake: Faster and Simpler

TLS 1.3 (released 2018) streamlined the handshake significantly:

Fewer Round Trips

TLS 1.2: 2 round trips (4 messages each way) TLS 1.3: 1 round trip (2 messages each way)

TLS 1.3 Flow

Client Hello + Key Share
        ────────────────────────────►
                                      Server Hello + Key Share
                                      {Encrypted Extensions}
                                      {Certificate}
                                      {Certificate Verify}
                                      {Finished}
        ◄────────────────────────────
{Finished}
        ────────────────────────────►

[Application Data]
        ◄───────────────────────────►

The client sends its key share in the first message, allowing the server to compute keys immediately.

0-RTT Resumption

TLS 1.3 even supports 0-RTT (zero round trip time) for returning visitors:

Client Hello + Key Share + Early Data
        ────────────────────────────►

The client can send encrypted data in the very first message! However, 0-RTT has replay attack risks, so it's used carefully.

What Gets Negotiated?

Cipher Suites

A cipher suite defines the algorithms used for:

Component	Purpose	Examples
Key Exchange	How to share keys	ECDHE, DHE, RSA
Authentication	Verify identity	RSA, ECDSA
Encryption	Encrypt data	AES-128-GCM, AES-256-GCM, ChaCha20
MAC	Message integrity	SHA-256, SHA-384

Example TLS 1.2 cipher suite:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
│     │     │        │    │     │
│     │     │        │    │     └── MAC algorithm
│     │     │        │    └──────── Mode (Galois/Counter)
│     │     │        └───────────── Encryption (AES 256-bit)
│     │     └────────────────────── Authentication
│     └──────────────────────────── Key Exchange
└────────────────────────────────── Protocol

TLS 1.3 simplified this:

TLS_AES_256_GCM_SHA384

TLS 1.3 only allows secure key exchanges (ECDHE), so it's not in the name.

Handshake Performance

Latency Impact

Each round trip adds latency:

Connection Type	Round Trips	Typical Latency
HTTP	1 (TCP)	~50ms
HTTPS (TLS 1.2)	3 (TCP + TLS)	~150ms
HTTPS (TLS 1.3)	2 (TCP + TLS)	~100ms
HTTPS (TLS 1.3 0-RTT)	1	~50ms

Optimization Techniques

Session Resumption: Reuse previous session parameters to skip full handshake.

TLS False Start: Start sending data before handshake completes (TLS 1.2).

OCSP Stapling: Server includes certificate status, avoiding extra lookups.

HTTP/2 and HTTP/3: Multiplex requests over single connection.

Common Handshake Failures

Handshake Timeout

Cause: Network issues, firewall blocking, server overload Fix: Check connectivity, firewall rules, server resources

Protocol Version Mismatch

Cause: Client and server don't share a common TLS version Fix: Update client/server to support modern TLS versions

Cipher Suite Mismatch

Cause: No common cipher suites between client and server Fix: Configure server with widely-supported cipher suites

Certificate Verification Failed

Cause: Invalid, expired, or untrusted certificate Fix: Install valid certificate with complete chain. See our troubleshooting guide for detailed solutions.

SNI Issues

Cause: Client doesn't send SNI, server can't identify which certificate to use Fix: Ensure client supports SNI (very old clients might not)

Debugging Handshake Issues

Using OpenSSL

# Full handshake debug
openssl s_client -connect example.com:443 -state -debug

# Check supported protocols
openssl s_client -connect example.com:443 -tls1_2
openssl s_client -connect example.com:443 -tls1_3

# Test specific cipher
openssl s_client -connect example.com:443 -cipher 'ECDHE-RSA-AES256-GCM-SHA384'

Using curl

# Verbose SSL output
curl -v https://example.com 2>&1 | grep -A 20 "SSL connection"

Using Wireshark

Capture and analyze TLS handshake packets:

Filter: tls.handshake
See each handshake message
Analyze cipher negotiation

Security Considerations

Forward Secrecy

Modern handshakes use ephemeral key exchange (ECDHE):

New keys for each session
Past sessions can't be decrypted if long-term key is compromised
TLS 1.3 requires forward secrecy

Downgrade Attacks

Attackers might try to force weaker protocols. Protections:

TLS 1.3 includes downgrade sentinels
Disable old protocols (SSLv3, TLS 1.0, TLS 1.1)
Use HSTS to prevent HTTP downgrade

Certificate Validation

The handshake is only secure if certificate validation is done properly:

Check certificate chain
Verify domain name
Check revocation status (OCSP/CRL)
Ensure certificate isn't expired

Key Takeaways

The TLS handshake establishes secure communication before any data transfer
TLS 1.2 requires 2 round trips; TLS 1.3 needs only 1
Both sides negotiate cipher suites and exchange key material
Certificate validation happens during the handshake
Modern handshakes provide forward secrecy
Performance optimizations like session resumption reduce latency

Want to see how your server handles TLS handshakes? Scan your domain with GuardSSL to check your TLS configuration and supported protocols.

The SSL/TLS Handshake Explained: What Happens When You Visit HTTPS