LiveChat 
Support 
TLS 1.3 vs TLS 1.2: What Changed and Why It Matters
Every time you load a site over HTTPS, two machines that have never met negotiate a shared secret in milliseconds, then encrypt everything that follows. The protocol governing that negotiation is TLS (Transport Layer Security). For roughly a decade, TLS 1.2 carried the web. In August 2018 the IETF published TLS 1.3 as RFC 8446, and it is not a minor revision. It is a deliberate stripping-away of two decades of accumulated cryptographic risk.
TLS 1.3 is faster and more secure than TLS 1.2 because it completes the handshake in one round trip instead of two, mandates forward secrecy, and removes every legacy algorithm that ever caused a real-world break. TLS 1.2, defined in RFC 5246, still supports older key-exchange methods and weak ciphers, which is exactly why TLS 1.3 dropped them. Both are still considered secure when configured well; the difference is that TLS 1.3 makes a bad configuration much harder to create.
Key Takeaways
• TLS 1.3 cuts the handshake to one round trip (1-RTT) versus two for TLS 1.2, so connections start faster, especially on high-latency links.
• TLS 1.3 makes forward secrecy mandatory by removing static RSA key exchange entirely, so a stolen private key cannot decrypt past traffic.
• The TLS 1.3 cipher suite list shrank from dozens to five AEAD-only suites, eliminating the weak options that caused attacks like RC4 and CBC padding oracles.
• TLS 1.3 adds 0-RTT resumption, a speed feature with a documented replay trade-off you should understand before enabling it.
• TLS 1.0 and 1.1 are deprecated (RFC 8996, 2021); the practical choice today is TLS 1.2 and 1.3 together.
The cleanest way to understand TLS 1.3 is to stop thinking of it as “TLS 1.2 plus features” and start thinking of it as “TLS 1.2 minus the dangerous parts.” Almost every serious TLS attack of the last fifteen years, BEAST, CRIME, POODLE, FREAK, Logjam, ROBOT, exploited an option that was optional and weak but still negotiable: an old cipher, a downgrade path, a flawed key exchange, a compression feature. TLS 1.2’s flexibility was its liability, because an attacker only needs to push two parties toward the weakest mutually-supported option. TLS 1.3’s central design decision was to delete the weak options rather than merely discourage them. You cannot misconfigure your way into RC4 or static RSA key exchange on TLS 1.3, because those code paths no longer exist in the protocol. That is the real story here, not raw speed. Speed is the headline; the removal of footguns is the substance.
What is the difference between TLS 1.3 and TLS 1.2?
TLS 1.3, published as RFC 8446 in August 2018, replaced TLS 1.2’s two-round-trip handshake with a single round trip, removed static RSA and Diffie-Hellman key exchange, and cut the cipher suite list to five AEAD-only options. TLS 1.2, from RFC 5246 (2008), remains widely deployed and secure when hardened, but it still permits the legacy algorithms that TLS 1.3 deliberately abandoned.
The headline differences fall into four buckets: handshake speed, key exchange, cipher suites, and forward secrecy. Each one is a response to a concrete weakness that surfaced during TLS 1.2’s long service life. Below is a side-by-side comparison.
| Aspect | TLS 1.2 (RFC 5246, 2008) | TLS 1.3 (RFC 8446, 2018) |
|---|---|---|
| Handshake round trips | 2-RTT for a full handshake | 1-RTT full handshake; 0-RTT on resumption |
| Speed | Slower start; extra latency before data flows | Faster start; one fewer round trip before encryption |
| Cipher suites | Dozens, including weak/legacy options (RC4, 3DES, CBC modes) | Five AEAD-only suites (e.g. AES-GCM, ChaCha20-Poly1305) |
| Key exchange | RSA, static DH, and ephemeral DH all permitted | Ephemeral (EC)DHE only — static RSA/DH removed |
| Forward secrecy | Optional; depends on chosen cipher suite | Mandatory for every connection |
| Deprecated features | Renegotiation, compression, custom DH groups allowed | Renegotiation, compression, and weak hashes removed |
| Adoption | Universally supported; still the floor for compatibility | Supported by all modern browsers and major servers |
The pattern across every row is the same: TLS 1.3 takes something that was *configurable* in 1.2 and makes the safe choice the *only* choice.
Why is the TLS 1.3 handshake faster?
The TLS 1.3 handshake is faster because it needs only one round trip (1-RTT) between client and server before encrypted application data can flow, compared with two round trips in TLS 1.2. On a connection with 100 ms of latency, removing a full round trip saves roughly 100 ms before the first byte of real data, which is the difference between a snappy page load and a sluggish one.
Here is the mechanism. In TLS 1.2, the client says hello, the server responds with its certificate and parameters, the client sends its key material, and only then does encryption begin, two complete back-and-forth exchanges. TLS 1.3 changes the choreography: the client guesses the key-exchange parameters the server will accept and sends its key share *in the very first message*. In most cases the server agrees, replies with its own key share and certificate, and the channel is encrypted after a single round trip.
TLS 1.3 can do this because it slashed the negotiation surface. With only a handful of supported groups and cipher suites, the client’s first-message guess is almost always right. TLS 1.2 could not safely guess, because it had too many combinations to negotiate first. So the speed gain is a direct consequence of the simplification, less to negotiate means fewer messages required.
What is 0-RTT and should you enable it?
0-RTT (zero round trip time) is a TLS 1.3 resumption feature that lets a returning client send encrypted application data in its *first* message, before the handshake even completes, eliminating round-trip latency entirely for repeat visits. It works by reusing a pre-shared key established in a previous session. The speed benefit is real and measurable on repeat connections, but it carries a specific, documented security trade-off.
The trade-off is replay. Because 0-RTT data is sent before the server can confirm the handshake is fresh, an attacker who captures that early data can resend it, and the server may process it twice. For an idempotent request like fetching a public page, replaying it is harmless. For a non-idempotent request like “transfer money” or “place order,” a replay could cause real damage.
The guidance in RFC 8446 is therefore precise: send only idempotent, replay-safe requests as 0-RTT data, and design your application so that early data cannot trigger state changes. In practice, most servers and CDNs that offer 0-RTT restrict it to GET requests and similar safe methods. My own rule of thumb: leave 0-RTT off unless you have a clear latency need and have explicitly audited which requests can travel in early data. Speed is never worth a replayed payment.
How does TLS 1.3 improve security?
TLS 1.3 improves security primarily by making forward secrecy mandatory and removing static RSA key exchange, the mechanism behind several high-profile decryption risks. In TLS 1.2, a server using static RSA key exchange could have all of its recorded past traffic decrypted if its private key were ever stolen. TLS 1.3 eliminates that entire class of risk by requiring ephemeral key exchange on every single connection.
Forward secrecy is the headline. With ephemeral (EC)DHE key exchange, each session generates fresh, throwaway key material. Even if an attacker records your encrypted traffic today and steals your server’s long-term private key next year, they cannot decrypt what they captured, because the per-session keys were discarded and never derived from the long-term key. TLS 1.2 *could* do this, but only if you chose an ephemeral cipher suite. TLS 1.3 makes it the only option.
The cipher suite purge is the substance. TLS 1.3 supports only AEAD (authenticated encryption with associated data) suites, AES-GCM, AES-CCM, and ChaCha20-Poly1305, and removes RC4, 3DES, static RSA, the SHA-1 hash, TLS compression, and renegotiation. Each of those was the root of a named attack. By deleting them rather than deprecating them, TLS 1.3 closes the downgrade negotiation that let attackers force the weakest mutually-supported option. There is simply nothing weak left to negotiate.
Should you disable TLS 1.2, or run 1.2 and 1.3 together?
For almost every website, the correct configuration today is to support both TLS 1.2 and TLS 1.3 while disabling the older TLS 1.0 and 1.1, which were formally deprecated by RFC 8996 in 2021. TLS 1.3 serves modern clients with maximum speed and safety; TLS 1.2 remains the compatibility floor for the small number of clients and middleboxes that have not yet caught up.
Disabling TLS 1.2 entirely is usually premature. While every current browser supports TLS 1.3, some API clients, older mobile devices, payment terminals, and corporate proxies still speak only TLS 1.2. Turning it off can silently break those connections with no clear error for the user. The safe, standard posture is a “1.2 + 1.3” policy: a modern client negotiates 1.3 automatically, and an older one falls back to a still-secure 1.2.
You should, however, disable TLS 1.0 and 1.1 without hesitation. They permit the weak ciphers and constructions behind POODLE and BEAST, and major compliance regimes already require them off. Here is the relevant directive on Nginx:
# Enable only modern, secure TLS versions
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off; # TLS 1.3 negotiates ciphers safely on its ownTo confirm which version a server actually negotiates, OpenSSL is the most direct tool:
# Force a TLS 1.3 connection and inspect the result
openssl s_client -connect example.com:443 -tls1_3
# Look for: "Protocol : TLSv1.3" in the outputIf the handshake succeeds and the output reports TLSv1.3, the server supports it. If it fails, retry with -tls1_2 to confirm the fallback path works.
How does DarazHost support modern TLS?
DarazHost serves HTTPS with both TLS 1.2 and TLS 1.3 enabled by default, and with the deprecated TLS 1.0 and 1.1 turned off, so every site gets the faster 1-RTT handshake and mandatory forward secrecy for modern visitors while keeping compatibility for older clients. The hardened cipher configuration is AEAD-only, matching the TLS 1.3 design philosophy, and free AutoSSL provisions and renews correctly-chained certificates automatically. You get fast, modern, properly-configured TLS without editing a single config file, and 24/7 support if you ever need to verify a setting.
For the full picture of how certificates, encryption, and trust fit together to make HTTPS work, see our pillar guide: SSL Certificates: The Complete Guide to How HTTPS, Encryption, and Trust Work. TLS version negotiation is one layer of that larger trust machinery, the layer that decides *how* your encrypted channel is built once the certificate has established *who* you are talking to.
Frequently asked questions
Is TLS the same as SSL? Not quite. SSL (Secure Sockets Layer) was the original protocol; TLS is its successor and the name has been used since 1999. SSL 2.0 and 3.0 are both broken and long deprecated. People still say “SSL certificate” out of habit, but the protocol your browser actually speaks today is TLS, specifically TLS 1.2 or TLS 1.3. The terms are used loosely, but technically only TLS is in use.
Is TLS 1.2 still secure in 2026? Yes, when configured correctly. TLS 1.2 remains secure if you disable its weak cipher suites and use ephemeral key exchange for forward secrecy. The catch is that TLS 1.2 *allows* insecure options, so security depends on hardening. TLS 1.3 is safer by default because the weak options were removed entirely. Running both, with TLS 1.0/1.1 disabled, is the recommended posture.
Will enabling TLS 1.3 break older browsers or clients? No, because TLS 1.3 is added alongside TLS 1.2, not instead of it. A client that does not understand TLS 1.3 simply negotiates TLS 1.2 instead during the handshake. Breakage only happens if you disable TLS 1.2 entirely while old clients still need it, which is why the standard advice is to keep both versions enabled.
What handshake speed improvement does TLS 1.3 actually give? TLS 1.3 removes one full round trip from the handshake (1-RTT versus 2-RTT in TLS 1.2). The real-world saving equals roughly one network round-trip time, often 50 to 150 ms depending on distance and connection quality. With 0-RTT resumption, a returning client can save the handshake latency entirely. The benefit is largest on high-latency mobile and long-distance connections.
Should I worry about TLS 1.0 and 1.1? Yes, you should disable them. Both were formally deprecated in RFC 8996 (2021) because they permit the weak ciphers and constructions behind attacks like POODLE and BEAST. Major compliance standards already require them off. There is no compatibility reason to keep them, as any client old enough to need TLS 1.0 has bigger security problems than your server.
