Message-by-message walk-through of TLS 1.3 (1-RTT) vs. TLS 1.2 (2-RTT)
This simulator walks through the TLS handshake message by message, letting you compare the streamlined 1-round-trip (1-RTT) TLS 1.3 flow against the older 2-round-trip (2-RTT) TLS 1.2 flow. Each message is explained in plain language: what it contains, which side sends it, and why it exists — turning an otherwise abstract cryptographic protocol into a concrete sequence you can step through.
TLS 1.3 (RFC 8446) collapses the handshake by having the client guess the key-exchange group and send its ephemeral (EC)DHE public key in the very first message (ClientHello). The server can then respond with its own key share, certificate, and Finished message all in a single flight — both sides have enough information to derive the shared secret after just one round trip. TLS 1.2, by contrast, negotiates the cipher suite and key-exchange parameters in the first round trip, then exchanges the actual key material and Finished messages in a second round trip — hence 2-RTT before application data can flow.
ClientHello/ServerHello negotiate the protocol version, cipher suite, and randomness that seeds all derived keys. The Certificate and CertificateVerify messages prove the server's identity by presenting a CA-signed certificate and a signature over the handshake transcript. The Finished messages — HMACs over the entire transcript — are the final integrity check: if any prior message was tampered with in transit, the HMACs will not match and the connection is aborted before any application data is exchanged.
A cipher suite has forward secrecy if a compromise of the server's long-term private key in the future cannot be used to decrypt past recorded sessions. (EC)DHE key exchange achieves this because a fresh ephemeral key pair is generated for every connection and discarded afterward. Static RSA key exchange (where the pre-master secret is encrypted directly with the server's long-term RSA public key) has no forward secrecy — if that key is ever compromised, every past session recorded by an eavesdropper can retroactively be decrypted. TLS 1.3 removed static RSA key exchange entirely for this reason.
0-RTT (zero round trip time) lets a client resume a previous TLS 1.3 session using a pre-shared key (PSK) and send encrypted application data in its very first flight, before the handshake even completes. It eliminates handshake latency entirely for repeat connections but is vulnerable to replay attacks, so servers typically restrict 0-RTT data to idempotent requests (e.g., HTTP GET) only.
Yes — this is a key difference from TLS 1.2. Because handshake traffic keys are derived immediately after ServerHello, the server's Certificate and CertificateVerify messages in TLS 1.3 are encrypted, hiding the server's certificate (and therefore which site is being visited) from a passive eavesdropper on the wire — though SNI in the ClientHello may still leak the hostname unless Encrypted Client Hello (ECH) is also used.
Legacy client and server compatibility. Some older embedded devices, corporate middleboxes, or legacy systems only support TLS 1.2 or earlier. Modern web browsers and servers negotiate the highest mutually supported version automatically, and most now default to TLS 1.3 with TLS 1.2 as fallback.
SSL (Secure Sockets Layer) is the predecessor to TLS; SSL 2.0 and 3.0 are both deprecated and insecure. TLS (Transport Layer Security) 1.0 through 1.3 are the modern, standardized successors — "SSL" is still used colloquially (e.g., "SSL certificate") but virtually all traffic described this way is actually using TLS.
Try our Enterprise IT Networks Studio
More calculators, simulators, and guides for this discipline.