Updates to TLS 1.3 Standards and What They Mean for Your Servers

Why TLS 1.3 Keeps Evolving

TLS 1.3 has been officially standardised since RFC 8446, but the story did not stop when the RFC number was published. Since then, browser vendors, operating systems, TLS libraries and the IETF have kept tightening recommendations around cipher suites, protocol versions, certificate choices and implementation details. For anyone running websites, APIs, email servers or SaaS platforms, these changes matter much more than a theoretical standards discussion. They decide which clients can connect, which audits you pass, how fast your pages load and how well you resist modern attacks.

In this article, I’ll walk through the most important updates to TLS 1.3 standards and guidance, what has effectively become “modern TLS 1.3” in 2025, and how to adjust your hosting, VPS or dedicated server setup to match. I’ll focus on practical impacts: which protocol versions and cipher suites to keep, what to phase out, and how these choices interact with compliance, SEO and user experience. Along the way, I’ll share the patterns we use at dchost.com when we deploy and maintain TLS for customer workloads.

The Core TLS 1.3 Standard in a Nutshell

Handshakes and 0‑RTT at a glance

TLS 1.3 radically simplified the handshake compared to 1.2. Instead of multiple round trips, most connections negotiate keys in one. The client sends its supported cipher suites, key share (e.g. X25519), ALPN (HTTP/2, HTTP/3, etc.) and extensions in the first flight; the server responds with its chosen parameters and certificate. This reduction directly improves Time To First Byte (TTFB) and makes Core Web Vitals like TTFB easier to optimise.

TLS 1.3 also introduces optional 0‑RTT data, where repeat clients can send some data before the handshake fully completes. While useful for latency-sensitive APIs, it comes with replay risks and is often disabled by default on security-conscious setups.

Stronger defaults by design

Unlike TLS 1.0/1.1/1.2, TLS 1.3 removes many of the historic footguns:

• No RSA key exchange (only ephemeral Diffie–Hellman, giving Perfect Forward Secrecy by default).
• No legacy ciphers like RC4, 3DES or generic CBC modes.
• Streamlined cipher suites that always pair strong AEAD algorithms (like AES‑GCM or ChaCha20‑Poly1305) with HKDF-based key derivation.

Those properties remain the same, but the recommended ways to use TLS 1.3 have evolved. The rest of this article focuses on those evolving recommendations.

Key Updates in TLS 1.3 Guidance and RFCs

1. Deprecation of TLS 1.0 and 1.1 is now effectively complete

Formally, TLS 1.0 and 1.1 were deprecated in a separate RFC (not in the TLS 1.3 spec itself). For a while, many admins kept them enabled “just in case” for very old clients. That window is effectively closed now:

• Modern browsers have long since removed support for TLS 1.0 and 1.1.
• Recent security recommendations and best-practice documents treat them as unsafe.
• Compliance standards like PCI DSS expect you to have them disabled for public-facing services.

If your server config still lists TLSv1 or TLSv1.1 alongside TLS 1.2/1.3, it’s time to remove them. At dchost.com, we ship modern images and managed hosting stacks with TLS 1.2 and 1.3 only for public HTTPS services. Where legacy compatibility is absolutely required (e.g. old embedded clients), we strongly recommend isolating those endpoints behind separate virtual hosts or even separate infrastructure segments.

2. Modern cipher suite recommendations for TLS 1.3

For TLS 1.3, the list of cipher suites is intentionally short, but community guidance has converged on a very small subset you should prioritise:

• TLS_AES_128_GCM_SHA256 – the workhorse; widely supported, fast on hardware with AES acceleration.
• TLS_CHACHA20_POLY1305_SHA256 – excellent for mobile devices or CPUs without AES‑NI; often preferred by browsers on ARM phones.
• TLS_AES_256_GCM_SHA384 – sometimes used where policy demands 256‑bit keys, though it offers marginal real‑world benefit over AES‑128‑GCM.

Recent guidance leans towards supporting all three, but with sensible ordering: AES‑128‑GCM first, ChaCha20‑Poly1305 second, AES‑256‑GCM third. This gives a good balance of speed, security and client flexibility.

On the TLS 1.2 side (which many clients still use), updated documents explicitly recommend AES‑GCM and ChaCha20‑Poly1305 suites and deprecate legacy CBC or SHA‑1‑based suites. If your configuration still contains anything with _CBC_ or _SHA (without 256/384) for TLS 1.2, treat that as a migration task for this quarter.

3. Curves, key sizes and certificate choices

Another area where recommendations for TLS 1.3 have stabilised is elliptic curves and certificate key types. The de‑facto modern set looks like this:

• Key exchange curves: X25519 and secp256r1 (also called P‑256) are the primary choices. X25519 is widely favoured for performance and robustness.
• Certificate keys: 2048‑bit RSA remains widely compatible; ECDSA with P‑256 is increasingly preferred on high‑traffic sites because it’s faster for handshakes.

Many real‑world deployments combine both: they serve dual ECDSA + RSA certificates so newer clients can enjoy faster ECDSA handshakes, while older systems still connect via RSA. If you want to go deeper into this topic, we’ve written about how to serve dual ECDSA + RSA certificates on Nginx and Apache without breaking compatibility.

In short, the trend in updated TLS 1.3 guidance is clear: prefer ECDSA where you can, keep 2048‑bit RSA around for compatibility, and prioritise X25519 in your key share list.

4. Updated best practices for TLS and DTLS in general

The IETF has also published updated best‑practice documents that cover both TLS 1.2 and 1.3, as well as DTLS 1.2/1.3. They emphasise:

• Disabling outdated protocol versions and weak ciphers.
• Using strong random number generation and safe session resumption mechanisms.
• Careful deployment of 0‑RTT, especially where replay would be dangerous (e.g. non‑idempotent POST requests).

Many of these recommendations are already integrated into modern TLS libraries and browser security policies, but server configuration still matters. A misconfigured cipher list or protocol setting can undo the protections TLS 1.3 offers by design.

Browser, OS and Library Changes You Should Care About

Browser policies are tightening around TLS 1.3

Even if the core TLS 1.3 spec hasn’t radically changed, browser behaviour around TLS has. Here are some trends we see when hosting customer sites at dchost.com:

• Browsers are quicker to warn users when a site uses outdated TLS settings (e.g. TLS 1.0/1.1, weak ciphers or old certificate chains).
• Modern browsers aggressively prioritise TLS 1.3 when available, falling back to TLS 1.2 only when necessary.
• HTTP/3 (which rides on QUIC) is now widely enabled, and its security story leans heavily on TLS 1.3 concepts—0‑RTT, modern AEAD ciphers and forward secrecy.

If your TLS configuration is half‑modern (TLS 1.3 enabled but with messy 1.2 fallbacks or odd cipher choices), you can see inconsistent behaviour between browsers. For example, one browser might happily negotiate TLS 1.3 with AES‑GCM, while another stumbles into an older TLS 1.2 CBC suite because of ordering mistakes. One of the easiest wins you can get this year is to clean up your cipher and protocol lists.

OS and TLS library defaults are getting stricter

Recent versions of OpenSSL, system libraries and application servers have also tightened their defaults:

• Disabling TLS 1.0/1.1 by default in many distributions.
• Reducing the set of enabled cipher suites, sometimes removing CBC entirely for TLS 1.2.
• Adopting secure curves like X25519 as the first choice for key exchange.

This is good news overall, but it can surprise you during upgrades. We’ve seen cases where a customer upgraded a Linux distribution, and suddenly a very old payment gateway integration or embedded IoT client could no longer connect because it only supported TLS 1.0 + legacy ciphers. The “problem” was not TLS 1.3 itself; it was that the environment had finally caught up with modern recommendations.

Before big OS or OpenSSL upgrades on your VPS or dedicated server, it’s worth planning a quick TLS regression test against critical integrations. Tools like openssl s_client, browser dev tools, and external scanners can help you see what will break before you flip the switch.

Emerging Directions: Encrypted ClientHello and Post‑Quantum TLS

From ESNI to ECH: hiding more metadata

One of the most interesting ongoing evolutions around TLS 1.3 is Encrypted ClientHello (ECH). Today, even with HTTPS, a passive observer can often see which hostname a user is visiting because the Server Name Indication (SNI) extension in the ClientHello is in cleartext. Earlier experiments like ESNI (Encrypted SNI) have evolved into ECH, which aims to encrypt the entire ClientHello for supported clients and servers.

ECH is not yet universally deployed, but browser and CDN support is growing. From a hosting perspective, you should be aware of it for a few reasons:

• It improves privacy by hiding which specific sites a user is visiting on a shared IP.
• It changes how certain network middleboxes and firewalls see TLS traffic; they can no longer rely on cleartext SNI.
• It relies on TLS 1.3–era capabilities and tight integration with DNS and certificates.

For most dchost.com customers, ECH will arrive as part of broader ecosystem support (browsers + CDNs + DNS). But designing your infrastructure with modern TLS 1.3 and clean SNI/certificate management today makes that transition much smoother.

Hybrid post‑quantum key exchange experiments

Another active area of work is bringing post‑quantum (PQ) cryptography into TLS. The concern is simple: a sufficiently powerful quantum computer could, in theory, break current public‑key systems like RSA and classical elliptic curves. To get ahead of that risk, the cryptography community is standardising new algorithms that are believed to be quantum‑resistant.

For TLS 1.3, the main approach being explored is hybrid key exchange:

• The client and server perform a normal TLS 1.3 key exchange (e.g. X25519) and a PQ key exchange.
• The final session keys are derived from both, so an attacker must break both the classical and PQ algorithms to recover them.

As of 2025, PQ TLS is still in the early adoption phase. You might see it in experimental builds or specific high‑security environments, but it’s not yet a mainstream hosting requirement. That said, the standards being drafted are explicitly built on top of TLS 1.3, not earlier versions. Keeping your stack fully TLS 1.3‑ready positions you well for a future where PQ handshakes become common.

Practical Impact on Your Hosting, VPS or Dedicated Server

Cleaning up protocol versions and cipher suites

Let’s translate all these updates into a concrete action list for a typical web server (Nginx or Apache) on a VPS or dedicated server:

1. Restrict protocol versions: enable only TLS 1.2 and 1.3 for public HTTPS endpoints. Remove TLS 1.0/1.1.
2. Define a modern cipher list:
   • For TLS 1.3: allow AES‑128‑GCM, AES‑256‑GCM and ChaCha20‑Poly1305.
   • For TLS 1.2: allow only AEAD suites (AES‑GCM, ChaCha20‑Poly1305) and disable CBC/RC4.
3. Order matters: put AES‑128‑GCM first, then ChaCha20‑Poly1305, then AES‑256‑GCM, unless you have a strict 256‑bit‑only policy.
4. Prefer modern curves: ensure X25519 and P‑256 are enabled and prioritised in your TLS library and web server settings.

If you want a hands‑on walkthrough of these choices for Nginx and Apache, we’ve covered them in detail in our article on TLS 1.3, OCSP Stapling and modern ciphers on Nginx/Apache.

RSA vs ECDSA vs dual certificates in practice

Updated TLS 1.3 recommendations don’t force you to abandon RSA, but they strongly encourage ECDSA where possible. The pattern we see working well in real deployments is:

• Use an ECDSA certificate (P‑256) as your primary certificate for most modern clients.
• Keep a 2048‑bit RSA certificate available for older clients that don’t fully support ECDSA.
• Serve both via your web server configuration, letting the client choose what it supports.

This approach shortens handshakes on modern devices, reduces CPU load and aligns with the direction of TLS 1.3 standards and browser guidance. On our infrastructure at dchost.com, we increasingly favour this dual‑cert model for high‑traffic sites, especially e‑commerce and SaaS platforms with a diverse user base.

Tuning TLS 1.3 on Nginx and Apache

Beyond cipher lists, there are a few TLS 1.3‑specific knobs worth understanding:

• 0‑RTT (early data): Most sites disable 0‑RTT or restrict it to idempotent GET requests, because replay attacks can be problematic for logins, payments or form submissions. Unless you have a clear use case and understand the risks, keeping it off is often the safer default.
• Session tickets and resumption: TLS 1.3 uses updated mechanisms for resuming sessions. Make sure your web server uses secure ticket keys and rotation schedules, and share keys only where appropriate between load‑balanced nodes.
• OCSP stapling: While not new with TLS 1.3, OCSP stapling nicely complements modern TLS by improving certificate revocation checking performance. We highly recommend enabling it, as described in our article on TLS 1.3, OCSP stapling and Brotli on Nginx.

Combining these with HTTP/2 or HTTP/3 support on a solid VPS or dedicated server gives you a modern, standards‑aligned HTTPS stack that both users and auditors will be happy with.

TLS 1.3, Compliance and Audit Requirements

PCI DSS and payment flows

Payment industry standards like PCI DSS have gradually caught up with TLS 1.3. While many documents still mention TLS 1.2 explicitly, the intent is clear: no weak protocol versions or ciphers for cardholder data. In practice, that translates to:

• Disabling TLS 1.0 and 1.1 for all payment‑related endpoints.
• Using only strong cipher suites (no CBC, no RC4, no export‑grade ciphers).
• Maintaining secure certificate lifecycles (shorter validity, automated renewal, proper revocation).

We’ve written a practical guide on this in our article PCI DSS for E‑Commerce, without the panic, where TLS configuration is one of the key pillars. TLS 1.3 generally makes compliance easier: if you enable it correctly and clean up your TLS 1.2 fallback, you’re already on the right side of most requirements.

Security headers and TLS go hand‑in‑hand

Updated TLS 1.3 deployments often happen alongside a refresh of HTTP security headers. For example:

• Strict-Transport-Security (HSTS) tells browsers to always use HTTPS for your domain.
• Content-Security-Policy (CSP) helps mitigate XSS by controlling which scripts and resources can load.
• X‑Content‑Type‑Options and X‑Frame‑Options close off common attacks around content sniffing and clickjacking.

These don’t change the TLS 1.3 protocol itself, but they significantly raise the overall security posture of your site. If you are planning a TLS refresh, it’s the perfect moment to also review your headers. Our guide on HTTP security headers (HSTS, CSP and more) walks through real‑world configurations for Nginx and Apache.

Email security and TLS 1.3

While much of the conversation about TLS 1.3 focuses on HTTPS, updated standards and practices also affect email:

• Modern MTAs increasingly support TLS 1.3 for SMTP over TLS (STARTTLS) connections.
• Protocol version and cipher choices affect deliverability to large providers, particularly when combined with policies like MTA‑STS and DANE.
• Strong TLS helps you prove to recipients that messages were delivered securely, which can be important in regulated industries.

If you run your own mail servers on a VPS or dedicated server, it’s worth aligning SMTP TLS settings with your HTTPS ones. We go deeper into this topic in our playbook on SMTP security with MTA‑STS, TLS‑RPT and DANE/TLSA, where TLS 1.3 is a central building block.

Action Plan: What to Change This Quarter

To turn all these TLS 1.3 updates into something concrete, here’s a pragmatic plan we often use with customers when modernising their stack on dchost.com infrastructure:

1. Inventory your endpoints
   • List all HTTPS services (websites, APIs, admin panels) and SMTP/IMAP/POP services.
   • Note which ones are public, which are internal and which handle sensitive data (payments, personal data, credentials).
2. Standardise protocol and cipher policies
   • Define a clear policy: TLS 1.2 + 1.3 only, AEAD ciphers only, modern curves only.
   • Apply this policy to Nginx/Apache, mail servers and reverse proxies.
3. Update certificates and keys
   • Move towards ECDSA + RSA dual certificates where it makes sense.
   • Ensure key sizes and algorithms align with current best practice (2048‑bit RSA, P‑256 ECDSA).
   • Automate renewals via ACME where possible.
4. Test with modern and legacy clients
   • Use multiple browsers, mobile devices and TLS scanners to verify that TLS 1.3 is being used where expected.
   • Identify any truly necessary legacy clients and consider isolated endpoints for them.
5. Harden around TLS
   • Add or refine HSTS, CSP and other security headers.
   • Review firewall rules and WAF behaviour in light of encrypted SNI and future ECH adoption.
   • Document your TLS policy for internal teams and auditors.

Once this baseline is in place, you can revisit it annually or when major changes land (e.g. stable post‑quantum TLS support or widespread ECH adoption).

How We Handle TLS 1.3 at dchost.com

At dchost.com, we treat TLS 1.3 as the default, not a special feature. On our hosting, VPS, dedicated server and colocation platforms, we structure things roughly as follows:

• Modern baselines by default: New environments are deployed with TLS 1.2 and 1.3 only, AEAD cipher suites, and modern curves (X25519/P‑256) enabled.
• Reasonable compatibility: We preserve compatibility with older – but still secure – clients by keeping well‑chosen RSA certificates and TLS 1.2 support where needed.
• Automation everywhere: ACME‑based certificate issuance and renewal, automated OCSP stapling, and configuration templates that reflect current best practices.
• Monitoring and logging: TLS‑related metrics (handshake errors, protocol versions negotiated, cipher usage) are tracked alongside general uptime and performance. If you are curious about how we think about uptime in general, we explain it in our article on what 99.9% uptime really means in hosting SLAs.

If you are using our shared hosting or managed VPS solutions, most of this is taken care of for you. If you manage your own Nginx/Apache on a self‑managed VPS or dedicated server, our team can still help you align your TLS configuration with the latest recommendations while respecting your application’s requirements and traffic patterns.

Wrapping Up

TLS 1.3 itself is a stable standard, but everything around it keeps evolving: cipher recommendations, browser policies, library defaults, privacy extensions like ECH and future‑looking work on post‑quantum key exchange. The net effect for anyone running websites, APIs or mail servers is clear: it’s not enough to just “enable TLS 1.3” once and forget it. You need a living TLS policy that you periodically review and tune.

The good news is that aligning with updated TLS 1.3 standards usually simplifies your stack. You disable old protocol versions, shrink your cipher list to a handful of strong options, adopt modern certificates and let the protocol do its job: secure, fast, reliable encryption. From there, you can layer on HTTP security headers, WAF rules and proper monitoring to complete the picture.

If you’d like to modernise your TLS setup on a new hosting, VPS, dedicated server or colocation environment, our team at dchost.com can help you design, deploy and maintain a configuration that matches current TLS 1.3 guidance and stays ready for what’s coming next—whether that’s encrypted ClientHello, post‑quantum handshakes or the next round of browser security changes.