TLS 1.3 migration and cipher selection

What changed in TLS 1.3

TLS 1.3 (RFC 8446, 2018) is not a small revision of 1.2. It removed features that caused years of vulnerabilities: RSA key exchange without forward secrecy, static Diffie-Hellman, CBC-mode ciphers, RC4, compression and renegotiation. Every TLS 1.3 connection uses ephemeral key exchange, so a stolen server key cannot decrypt recorded past traffic.

The handshake is also faster. A new connection needs one round trip before application data flows, compared with two in TLS 1.2, and more of the handshake is encrypted, including the server certificate. An optional 0-RTT mode lets returning clients send data immediately, at the cost of allowing that early data to be replayed.

Which protocol versions to allow

RFC 8996 formally deprecated TLS 1.0 and 1.1 in 2021, and major browsers had already removed support. Keeping them enabled only helps very old clients while exposing everyone to downgrade-related weaknesses and failing compliance scans. For public websites, the practical baseline is TLS 1.2 and TLS 1.3.

A TLS 1.3-only configuration, what Mozilla calls the modern profile, is reasonable for APIs and internal services whose clients you control. Public sites usually keep TLS 1.2 for older operating systems, embedded devices and some corporate proxies. The TLS Checker shows which version a connection negotiated.

Choosing cipher suites

TLS 1.3

TLS 1.3 defines a small set of suites, and the ones commonly enabled are all strong. Most servers ship with sensible defaults, so there is usually nothing to configure. The suite only chooses the AEAD cipher and hash; key exchange and signature algorithms are negotiated separately.

TLS 1.2

TLS 1.2 is where configuration matters. Allow only suites with ECDHE key exchange, for forward secrecy, and AEAD ciphers. RFC 9325 (BCP 195) gives the IETF's current recommendations and matches what maintained profiles use.

Scanner findings explained

TLS scanners report findings by the names of old attacks, which makes them hard to prioritise. Most of them disappear together once TLS 1.0 and 1.1 are disabled and TLS 1.2 is limited to ECDHE with AEAD ciphers. The table maps common findings to the configuration change that removes them.

Findings about HTTP headers, such as a missing HSTS header, often appear in the same report but are fixed in the web server's header configuration rather than the TLS settings. The HTTP Headers Checker lists those separately.

Session resumption and performance

A full handshake costs a round trip and some CPU, so clients resume earlier sessions when they can. TLS 1.3 replaced the older session ID and ticket mechanisms with pre-shared keys derived from a previous session, and it still combines resumption with a fresh key exchange by default. That keeps forward secrecy for resumed sessions too.

For TLS 1.2, session tickets encrypted with a long-lived key weaken forward secrecy, because anyone who obtains that key can decrypt the recorded sessions whose tickets it protected. Mozilla's profiles therefore disable TLS 1.2 session tickets unless the ticket keys are rotated frequently. A shared session cache on the server gives most of the performance benefit without that trade-off.

HTTP/2 and HTTP/3 reduce the number of TLS handshakes further by reusing one connection for many requests. HTTP/3 runs over QUIC, which integrates TLS 1.3 into the transport; enabling it does not change your certificate but does need UDP port 443 open.

Server configuration examples

The examples follow Mozilla's intermediate profile at the time of writing. Generate the current version for your exact server and library versions with the Mozilla SSL Configuration Generator, because recommendations change. Reload the server and scan it after every change.

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;
ssl_session_timeout 1d;
ssl_session_cache shared:TLS:10m;
ssl_session_tickets off;

SSLProtocol             -all +TLSv1.2 +TLSv1.3
SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
SSLHonorCipherOrder     off
SSLSessionTickets       off

example.com {
    tls {
        protocols tls1.2 tls1.3
    }
}

ssl_prefer_server_ciphers off lets clients choose among the allowed suites, which is the current recommendation because every allowed suite is strong and clients know whether they have AES hardware acceleration. The TLS 1.3 suites are configured separately in OpenSSL-based servers and rarely need changing.

Behind a CDN or load balancer, the edge terminates TLS for visitors, so its TLS policy is what the TLS Checker and browsers see. Configure the minimum version there, and use TLS between the edge and your origin as well.

Certificates and key types

Keep private keys on the servers or edge platforms that terminate TLS, readable only by the service account that needs them. Rotate the key when a certificate is reissued after any suspected exposure, not just the certificate.

The certificate's key type determines which suites can be used. ECDSA P-256 certificates are smaller and faster to verify than RSA; RSA 2048 remains universally supported. Many servers can serve both at once and pick one per client, although with current clients a single ECDSA or RSA certificate is fine.

• Serve the full chain: the leaf certificate plus intermediates, not the root.
• Automate renewal; publicly trusted certificate lifetimes keep getting shorter under CA/Browser Forum rules.
• Monitor expiry independently of the renewal job, for example with the TLS Checker in a scheduled check or the XGM API.
• Add HTTP Strict Transport Security once HTTPS works everywhere; the HSTS guide explains the rollout.

Testing your configuration

Test from outside your network, because proxies and CDNs change what visitors see. Check that TLS 1.3 and 1.2 connect, that 1.0 and 1.1 are refused, and which suites the server offers. The commands below use OpenSSL and nmap, both widely available.

# TLS 1.3 should connect
openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null 2>/dev/null | grep -E 'Protocol|Cipher'

# TLS 1.1 should fail (depending on your OpenSSL build, the client may refuse locally)
openssl s_client -connect example.com:443 -servername example.com -tls1_1 </dev/null

# list offered protocol versions and suites
nmap --script ssl-enum-ciphers -p 443 example.com

Automate the scan. Running the same checks weekly, or after every infrastructure change, catches regressions such as a new load balancer with default settings or a certificate that was renewed with an incomplete chain. Store the results so you can see when a change happened, not just that the current state is wrong.

When a check fails only from some locations, suspect a CDN or anycast setup where different edge locations run different configurations, or a DNS change that has not reached every resolver yet. Testing the IP addresses behind the host name one by one, with --resolve in curl or -connect to a specific IP in OpenSSL, narrows it down quickly.

Remember other TLS endpoints: mail servers on ports 25, 465 and 587, IMAP on 993, and admin panels on non-standard ports. They often run different software with older defaults. The Port Scanner shows which ports are reachable from the internet.

Compatibility and rollout

Disabling TLS 1.0 and 1.1 affects only clients that cannot do TLS 1.2, which today means very old operating systems, outdated embedded devices and some legacy integrations. If you have server logs with protocol versions, check how many requests still use the old versions before switching them off. Many teams find the number is effectively zero apart from scanners.

1. Log the negotiated protocol and cipher for a week, if your server supports it.
2. Identify remaining old clients; contact the owners of important integrations.
3. Disable TLS 1.0 and 1.1 and weak TLS 1.2 suites in one change, and scan.
4. Watch error rates and support requests for a few days.
5. Revisit the configuration yearly against the current Mozilla profile.

FAQ

Sources

• RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
• RFC 8996: Deprecating TLS 1.0 and TLS 1.1
• RFC 9325: Recommendations for Secure Use of TLS and DTLS (BCP 195)
• RFC 7568: Deprecating Secure Sockets Layer Version 3.0
• Mozilla SSL Configuration Generator
• Mozilla wiki: Server Side TLS