How to set up TLS securely

Which protocols and cipher suites your server offers decides how well an HTTPS connection really protects. A current setup is short and works with every browser in use today.

How it works

Every HTTPS connection starts with the TLS handshake. The browser lists the protocol versions and cipher suites it supports, and the server picks from them. A cipher suite decides how browser and server agree on the key, what they encrypt with and how they check that nothing was changed on the way.

If the server also offers old versions or weak suites, an attacker on the same network can try to push the connection down to exactly those. That is why what counts is not only what a current browser gets, but everything the server accepts at all.

Forward secrecy means that every connection gets its own short-lived key (ECDHE). Whoever steals the server's key later still cannot open recorded connections. With the old RSA key exchange they can.

Post-quantum key exchange protects against “record now, decrypt later”: the hybrid method X25519MLKEM768 combines the classic X25519 with ML-KEM, which also holds against future quantum computers. Chrome, Firefox, Safari and Edge offer it by default.

What matters

  • TLS 1.2 and TLS 1.3 only. TLS 1.0 and 1.1 have been officially deprecated since 2021 (RFC 8996), SSL 2.0 and 3.0 have been broken for years. No current browser needs them.
  • No insecure suites. RC4, DES, 3DES, EXPORT, NULL and anonymous suites belong off the list. Best keep only suites with AES-GCM or ChaCha20-Poly1305 and ECDHE.
  • Forward secrecy for all. Suites named TLS_RSA_WITH_… agree on the key without forward secrecy. Current browsers do not need them.
  • Hardening is usually there already. Downgrade protection (TLS_FALLBACK_SCSV), secure renegotiation and compression switched off come with current TLS libraries. If they are missing, the server's software is outdated.
  • Post-quantum group first. With OpenSSL 3.5 or later (or BoringSSL) the server can do X25519MLKEM768; put the group at the start of the list.
  • Behind a CDN the TLS connection ends at the CDN. Then you set protocols and suites there, for example in Cloudflare's dashboard under the minimum TLS version.

How to set it up

The lines follow Mozilla's “intermediate” recommendation (SSL Configuration Generator). They suit every browser of recent years.

Web server
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1:secp384r1;
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_tickets off;
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLOpenSSLConfCmd Groups X25519MLKEM768:X25519:prime256v1:secp384r1
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
SSLCompression off
SSLSessionTickets off

Only OpenSSL 3.5 knows X25519MLKEM768. With an older version the web server does not start with this group; leave it out until the system is updated. The TLS 1.3 suites are not in the list, they are always secure. Afterwards check again whether old clients you really need (payment terminals or old interfaces, say) still connect.

More on HTTPS and transport

Check your website now

The security check shows within seconds which headers are missing, with ready lines to copy.

Check website