TLS 1.3, finalized in 2018, is the current standard and a genuine redesign rather than an incremental patch — it removed a long list of legacy options that had been the root cause of numerous TLS 1.2-era vulnerabilities, while also cutting handshake latency roughly in half for new connections.
The handshake got faster
TLS 1.2 requires two full round trips between client and server before any application data can be sent: one to negotiate the protocol and cipher suite, another to complete the key exchange. TLS 1.3 collapses this by having the client send its likely key exchange parameters in the very first message, based on the assumption that the server's configuration hasn't changed since the last known negotiation — a bet that pays off the vast majority of the time. The result is a single round trip, and with "0-RTT" resumption for repeat visitors, sometimes effectively zero additional round trips at all.
A meaningfully smaller attack surface
A large share of TLS's historical vulnerabilities — including well-known ones like POODLE, FREAK, and Logjam — exploited legacy features or weak algorithm options that TLS 1.2 still permitted for backward compatibility. TLS 1.3 doesn't patch around these; it removes the offending features outright: no more RSA key exchange without forward secrecy, no more CBC-mode ciphers with their associated padding oracle risks, no more renegotiation (a mechanism that had its own history of exploitable bugs), and no more compression at the TLS layer (which enabled the CRIME attack).
Forward secrecy is no longer optional
In TLS 1.2, forward secrecy depended on which cipher suite was negotiated — a server could still be configured to allow non-ephemeral key exchange, silently losing this protection. TLS 1.3 removed non-ephemeral key exchange from the protocol entirely, meaning every TLS 1.3 session gets forward secrecy by default, with no configuration choice that could accidentally disable it.
Server-side and browser support today
TLS 1.3 is supported by all current major browsers and most modern server software (Nginx, Apache, most CDNs) with minimal configuration — often just requiring an up-to-date version and explicitly listing 1.3 among supported protocol versions. TLS 1.0 and 1.1 have been formally deprecated and are disabled by default in modern browsers; if your server still needs to support very old clients, TLS 1.2 remains a reasonably secure floor, but there's rarely a good reason not to also enable 1.3 alongside it.
What to actually check on your own server
Run an SSL scan tool against your domain and look specifically for which protocol versions are offered. The practical target for most sites today is: TLS 1.3 enabled, TLS 1.2 enabled for compatibility, and TLS 1.1/1.0/SSL entirely disabled.
0-RTT: TLS 1.3's fastest mode, and its one real trade-off
For a returning visitor, TLS 1.3 supports an optional "0-RTT" (zero round-trip time) mode, letting the client send encrypted application data in its very first message, before the handshake has even fully completed, by reusing parameters from a previous session. This is the fastest possible reconnection, but it comes with a specific, narrow security trade-off: 0-RTT data doesn't have the same forward-secrecy and replay protection as the rest of the session, meaning an attacker who can intercept and resend that very first 0-RTT message could, in specific circumstances, cause it to be processed twice by the server. For this reason, 0-RTT is generally recommended only for requests that are safe to process more than once (like a GET request for a static page), and many servers disable it by default for anything state-changing, such as a login or payment submission.
TLS 1.3 also changed what's visible on the wire
In TLS 1.2, a fair amount of handshake content — including the server's certificate — was sent unencrypted, visible to anyone observing network traffic even though they couldn't decrypt the actual page content that followed. TLS 1.3 encrypts the certificate exchange and most of the rest of the handshake as well, once an initial shared secret is established, meaningfully reducing what a network observer can learn about a connection even without breaking the encryption itself. This is a genuine, if less commonly discussed, privacy improvement that came bundled with the same redesign that improved speed and removed legacy cipher suites.
What migrating to TLS 1.3 actually involves
For most modern hosting, enabling TLS 1.3 is a matter of confirming your web server software is a recent enough version and explicitly listing 1.3 in your supported protocol configuration — it does not require a new certificate, since TLS 1.3 works with the same X.509 certificates as TLS 1.2. The main compatibility consideration is client-side: a small, shrinking population of very old browsers and API clients don't support 1.3, which is why disabling TLS 1.2 entirely is usually premature for a public-facing site, even while enabling 1.3 alongside it is close to a no-downside improvement.
What migrating to TLS 1.3 actually involves in practice
For most modern hosting, enabling TLS 1.3 is simply a matter of confirming your web server software is a recent enough version and explicitly listing 1.3 among supported protocol versions — it doesn't require a new certificate, since TLS 1.3 works with the same X.509 certificates as TLS 1.2. The main compatibility consideration is client-side: a small, shrinking population of very old clients don't support 1.3 yet, which is why disabling TLS 1.2 entirely is usually premature.
Why the two protocols can safely run side by side
There's no conflict in supporting both TLS 1.2 and TLS 1.3 simultaneously on the same server — during the handshake, the client and server simply negotiate the highest version both sides support, meaning a TLS 1.3-capable visitor automatically gets 1.3's benefits while an older client falls back gracefully to 1.2 without either connection type interfering with the other.
What TLS 1.3 also encrypts that TLS 1.2 left exposed
TLS 1.2 sent a fair amount of handshake content — including the server's certificate — unencrypted, visible to anyone observing network traffic even though the page content that followed was protected. TLS 1.3 encrypts the certificate exchange and most of the rest of the handshake too, once an initial shared secret is established, a meaningful privacy improvement beyond the more commonly discussed speed and security benefits.
0-RTT: the fastest mode, and its one narrow trade-off
For a returning visitor, TLS 1.3 supports an optional 0-RTT mode letting the client send encrypted data in its very first message, before the handshake even fully completes. This is the fastest possible reconnection, but 0-RTT data lacks the same forward-secrecy and replay protection as the rest of the session, which is why it's generally recommended only for requests safe to process more than once, like a simple page load rather than a payment submission.
Enabling TLS 1.3 alongside 1.2 is close to a no-downside improvement for any modern server — faster handshakes, mandatory forward secrecy, and a meaningfully smaller attack surface, with essentially no compatibility cost for a mainstream audience.
A quick closing checklist for a modern protocol configuration
Confirm TLS 1.3 is enabled, TLS 1.2 remains available as a compatibility fallback, and TLS 1.0/1.1 are explicitly disabled — three settings covering the current recommended baseline for virtually any server.