Every HTTPS connection begins with a TLS handshake — a negotiation where the client and server agree on encryption parameters before any application data flows. TLS 1.3, standardized in RFC 8446, replaced the long-serving TLS 1.2 (RFC 5246) with a redesigned handshake that is both faster and considerably harder to misconfigure insecurely.
Direct Answer: TLS 1.2 typically requires two full round trips between client and server before application data can be sent. TLS 1.3 reduces this to a single round trip, and supports 0-RTT (zero round-trip time) resumption for repeat connections to a server the client has already visited, sending encrypted application data in the very first packet. TLS 1.3 also removes a long list of legacy cipher suites and features that had been the source of real-world attacks against TLS 1.2 deployments.
1. The Handshake: Two Round Trips vs One
In TLS 1.2, the client and server negotiate the protocol version, cipher suite, and key exchange material across multiple back-and-forth messages: ClientHello → ServerHello, Certificate, ServerKeyExchange, ServerHelloDone → ClientKeyExchange, ChangeCipherSpec, Finished → ChangeCipherSpec, Finished. In practice this consumes two round trips (2-RTT) before the first byte of encrypted application data can be exchanged.
TLS 1.2 Handshake (2 Round Trips):
Client ──ClientHello──────────────────────► Server
Client ◄─ServerHello+Cert+KeyExchange───── Server (RTT 1)
Client ──ClientKeyExchange+Finished──────► Server
Client ◄─Finished──────────────────────────Server (RTT 2)
Client ──Application Data─────────────────► Server
TLS 1.3 collapses this into a single round trip (1-RTT). The client sends its supported key-share guesses in the very first ClientHello, and the server can respond with its certificate, key share, and Finished message in one flight — allowing the client to start sending encrypted application data after just one round trip.
TLS 1.3 Handshake (1 Round Trip):
Client ──ClientHello + Key Share──────────► Server
Client ◄─ServerHello + Key Share + Cert +
Finished──────────────────────── Server (RTT 1)
Client ──Finished + Application Data──────► Server
For repeat visits, TLS 1.3 also supports 0-RTT resumption: if the client has connected to the server before and holds a resumption ticket (a "pre-shared key"), it can send encrypted application data in the very first flight, with no round trip required before data starts flowing. This trades a small, well-documented replay-attack risk (mitigated by only allowing 0-RTT for idempotent requests) for a meaningful latency win on repeat connections — a common pattern for returning visitors loading a website.
2. What TLS 1.3 Removed (and Why)
TLS 1.3 is not just a faster handshake — it is a security-hardening rewrite that deliberately eliminates features and cipher suites that had caused real vulnerabilities in TLS 1.2 deployments:
| Removed Feature | Problem It Caused in TLS 1.2 | TLS 1.3 Behavior |
|---|---|---|
| RSA key exchange (static, no forward secrecy) | If a server's private key was later compromised, all past recorded traffic encrypted with it could be decrypted retroactively | Only (Elliptic Curve) Diffie-Hellman Ephemeral key exchange is allowed, guaranteeing forward secrecy for every session |
| RC4 stream cipher | Statistical biases in the RC4 keystream allowed practical plaintext-recovery attacks | Removed entirely — not negotiable |
| DES / 3DES (Triple DES) | Small block size enables the Sweet32 birthday-bound attack on long-lived connections | Removed entirely |
| Compression (TLS-level) | Enabled the CRIME attack, which recovers secrets by observing compressed ciphertext length | Removed entirely |
| Renegotiation | Insecure renegotiation was exploited in man-in-the-middle injection attacks (addressed partially in TLS 1.2 via RFC 5746, but the underlying complexity remained) | Removed — TLS 1.3 has no renegotiation mechanism |
By dropping these options outright, TLS 1.3 also shrinks the negotiable cipher-suite list dramatically. TLS 1.2 servers could accidentally offer a weak cipher through misconfiguration; TLS 1.3 simply does not offer that choice.
3. What to Actually Check With an SSL Checker
When running a website through an SSL/TLS checker, the most actionable finding is not the certificate's expiration date alone — it's which protocol versions the server still accepts. A server can hold a perfectly valid certificate while still negotiating obsolete protocol versions for clients that request them.
- Confirm TLS 1.2 and TLS 1.3 are enabled. These are the only two versions considered acceptable by current browsers and compliance frameworks.
- Confirm TLS 1.0 and TLS 1.1 are disabled. Both were formally deprecated in RFC 8996 (March 2021) and are treated as a security gap by PCI DSS, most modern compliance frameworks, and major browsers, which have removed UI support for negotiating them.
- Confirm SSL 2.0 and SSL 3.0 are disabled. These predate the TLS rename and have known, exploitable flaws (SSL 3.0's POODLE vulnerability among them).
- Check the certificate chain and cipher suite alongside protocol version — a modern protocol paired with a weak or expired certificate is still a finding worth fixing.
Compliant Server Configuration:
TLS 1.0 ──► Disabled
TLS 1.1 ──► Disabled
TLS 1.2 ──► Enabled (fallback for older clients)
TLS 1.3 ──► Enabled (preferred, negotiated when both sides support it)
Serving TLS 1.0/1.1 alongside 1.2/1.3 "just in case" is no longer a neutral choice — it is considered an active security gap in most compliance frameworks and needlessly widens the attack surface for downgrade attacks.
Check which protocol versions and cipher suites your server actually serves using our interactive ssl-certificate-checker.
4. Frequently Asked Questions (FAQs)
Does upgrading to TLS 1.3 break compatibility with older clients?
Servers can (and typically do) support both TLS 1.2 and TLS 1.3 simultaneously, letting modern clients negotiate 1.3 while older clients that only support 1.2 still connect securely. The compatibility concern is with TLS 1.0/1.1, which should be disabled rather than kept as a fallback.
Is 0-RTT resumption in TLS 1.3 actually safe to enable?
0-RTT data carries a theoretical replay-attack risk, since an attacker who intercepts the first flight could resend it. Server implementations mitigate this by only permitting 0-RTT for requests considered safe to replay (idempotent operations), and many deployments disable 0-RTT entirely for anything security-critical while still benefiting from the standard 1-RTT handshake improvement.
Why do some SSL checker tools still flag a site using only TLS 1.2?
TLS 1.2 alone is still considered acceptable by current standards as long as it is configured with strong (forward-secret) cipher suites and modern key exchange. A checker flags TLS 1.2-only configurations mainly when they still allow legacy ciphers like static RSA key exchange or CBC-mode suites vulnerable to older padding attacks — not simply for lacking TLS 1.3.
References: IETF RFC 5246 (TLS 1.2), IETF RFC 8446 (TLS 1.3), IETF RFC 8996 (Deprecating TLS 1.0 and TLS 1.1).
