About this tool
Understanding the TLS 1.3 handshake
The TLS 1.3 handshake is the foundation of secure communication on the modern web. Every HTTPS connection begins with this exchange, where the client and server agree on encryption parameters, authenticate the server's identity, and derive the symmetric keys used to encrypt application data. Unlike its predecessor TLS 1.2, which required two full round trips before any encrypted data could flow, TLS 1.3 completes the handshake in a single round trip. This reduction in latency is especially impactful for mobile users on high-latency networks, where each additional round trip can add hundreds of milliseconds to page load times.
The visualizer above shows every message in the handshake sequence with the exact fields and values exchanged. Click on any step to see the cryptographic details, including the specific cipher suites, key exchange parameters, and certificate verification process. If you are debugging authentication tokens exchanged after the TLS handshake completes, the JWT Debugger can help you inspect the claims and expiration of JWT-formatted bearer tokens.
TLS and real-world infrastructure
In production environments, TLS configuration directly impacts both security posture and application performance. Misconfigured TLS can lead to connection failures, degraded performance from unnecessary round trips, or security vulnerabilities if weak cipher suites are enabled. Tools like Qualys SSL Labs grade your server's TLS configuration and flag issues such as missing HSTS headers, weak key sizes, or support for deprecated protocol versions. Understanding the handshake helps you diagnose issues like certificate chain errors, SNI mismatches, and session resumption failures.
When a TLS handshake fails and your application retries the connection, the retry timing matters. Aggressive retries against a server with certificate issues will not help but will consume resources. Use the Retry Calculator to model appropriate backoff strategies for connection-level failures, and the CORS Tester to verify that your cross-origin requests are correctly configured after the secure connection is established.
Frequently Asked Questions
Why is TLS 1.3 faster than TLS 1.2?
TLS 1.3 reduces the handshake from two round trips to just one by combining several previously separate steps. In TLS 1.2, the client and server first negotiate cipher suites, then exchange key material in a second round trip before encrypted communication can begin. TLS 1.3 eliminates this overhead by having the client send its key share optimistically in the very first message (ClientHello), allowing the server to derive encryption keys immediately and respond with encrypted data. The protocol also removes the ChangeCipherSpec message and the separate ServerKeyExchange step, both of which added latency in TLS 1.2. For repeat connections, TLS 1.3 supports 0-RTT resumption, where the client can send encrypted application data in its very first packet using a pre-shared key from a previous session. This means a returning visitor to a website can start receiving content before the handshake even completes. Google reported that enabling TLS 1.3 reduced their page load times by an average of 100 milliseconds. Cloudflare observed similar improvements across their network, with the single round-trip handshake being especially beneficial for mobile users on high-latency cellular connections.
What cipher suites does TLS 1.3 support?
TLS 1.3 dramatically simplified the cipher suite landscape by removing all legacy and insecure algorithms. The specification defines only five cipher suites: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_CCM_SHA256, and TLS_AES_128_CCM_8_SHA256. All of them use Authenticated Encryption with Associated Data (AEAD), which combines encryption and integrity verification in a single operation. This is a massive reduction from TLS 1.2, which supported over 300 cipher suite combinations including weak algorithms like RC4, DES, and export-grade 40-bit ciphers that were vulnerable to known attacks like BEAST, POODLE, and SWEET32. TLS 1.3 also removed RSA key exchange entirely, mandating ephemeral Diffie-Hellman (either ECDHE with X25519 or P-256, or finite-field DHE). This ensures forward secrecy by default: even if the server's private key is compromised in the future, previously recorded sessions cannot be decrypted. The reduced set means there are no weak configurations to accidentally enable, making TLS 1.3 secure by default rather than secure by careful configuration.
How does TLS 1.3 protect against downgrade attacks?
TLS 1.3 includes a specific mechanism to prevent attackers from forcing a connection to use an older, weaker protocol version. When a TLS 1.3-capable server receives a ClientHello and decides to negotiate TLS 1.2 or lower (perhaps because the client advertised support for older versions), the server embeds a special sentinel value in the last 8 bytes of its ServerHello random field. For TLS 1.2, this value is 0x44 0x4F 0x57 0x4E 0x47 0x52 0x44 0x01 (the ASCII string "DOWNGRD" followed by 0x01). For TLS 1.1 or lower, the final byte is 0x00. A TLS 1.3-capable client that receives a ServerHello for an older version checks for this sentinel. If it finds the marker, the client knows the server actually supports TLS 1.3 and that a man-in-the-middle attacker is forcing a downgrade. The client then aborts the connection with an illegal_parameter alert. This mechanism defeated attacks like POODLE and Logjam that exploited version negotiation weaknesses in earlier TLS versions. Additionally, TLS 1.3 encrypts the Certificate and CertificateVerify messages, preventing passive observers from seeing the server certificate and making active interception more difficult to execute without detection.