TLS configuration best practices: protocols, ciphers, and forward secrecy

TLS configuration decides how strong your encryption actually is - which protocol versions, cipher suites, and key-exchange parameters a server accepts. A valid certificate says nothing about any of it. Here are the best practices, and how SecRift scores yours.

Two servers can present a perfectly valid certificate and still offer very different TLS. One accepts only TLS 1.2 and TLS 1.3 with modern AEAD ciphers. The other still answers on TLS 1.0 with RC4 in the mix, because nobody has touched the config in years. Both pass a certificate check. Only one is actually configured well. This guide covers TLS configuration best practices - what to accept, what to disable, and how SecRift scores the result across six dimensions.

What is TLS configuration?

TLS configuration is the set of choices a server makes about how it negotiates encryption: which protocol versions it accepts (TLS 1.0 through 1.3, or older SSL), which cipher suites it offers within those versions, whether key exchange is ephemeral or static, and which optional features - compression, 0-RTT early data - are switched on.

None of this is about identity. A certificate proves the server is who it claims to be. Configuration governs the cryptographic strength of the channel once that identity is established. A server can have a flawless certificate chain and still negotiate a connection an attacker can downgrade, decrypt, or replay.

How TLS negotiation works

Every connection starts with a handshake. The client sends the protocol versions and cipher suites it supports, and the server picks the strongest combination it also allows. The security of the session is therefore capped by what the server is willing to accept - not by what a modern client would prefer.

That is the whole reason configuration matters. If a server still lists TLS 1.0 and an RC4 cipher as acceptable, an attacker who can influence the handshake can steer the negotiation down to that weak option, even when both endpoints support something far stronger. Good configuration is about removing bad choices from the menu, so the weakest thing on offer is still safe.

Why TLS configuration matters

The baseline is set by RFC 9325 (BCP 195): TLS 1.2 as the absolute minimum, TLS 1.3 recommended, ephemeral key exchange for forward secrecy, and AEAD cipher suites only. Every dimension below maps to a real, well-documented risk that this baseline closes:

• Outdated protocols. TLS 1.0 and 1.1 are formally deprecated by RFC 8996 - they predate authenticated encryption and enabled attacks like BEAST. SSLv2 and SSLv3 are broken outright: SSLv3 is the root of POODLE (CVE-2014-3566), and SSLv2 carries the flaws behind DROWN.
• Weak ciphers. RC4 is banned by RFC 7465, 3DES is the root of SWEET32 (CVE-2016-2183), EXPORT-grade suites underpin FREAK, and NULL or anonymous suites offer no encryption or no authentication at all.
• No forward secrecy. Static RSA or static (EC)DH key exchange means one leaked private key decrypts every session ever recorded. Ephemeral (EC)DHE gives each session its own key, so past traffic stays protected - the direct defense against "harvest now, decrypt later."
• Optional features left on. TLS compression enables CRIME (CVE-2012-4929), and TLS 1.3 0-RTT early data can be replayed without detection.

Common mistakes

The single most common mistake is leaving old options enabled "for compatibility" long after any real client needed them - a deprecated protocol version undermines every strong choice layered on top of it.

The most common misdiagnosis is the DHE vs ECDHE trap, and it is worth spelling out because it trips people up: ECDHE is not a weak key exchange. Seeing "DHE" in a cipher suite name does not automatically mean a weak Diffie-Hellman group.

• DHE (finite-field Diffie-Hellman) is only weak when the negotiated group is small - below 2048 bits, the threshold past which Logjam (CVE-2015-4000) becomes a practical downgrade attack.
• ECDHE (elliptic-curve Diffie-Hellman) is a different mechanism with a different unit of strength. A 256-bit curve like secp256r1 or X25519 is entirely modern and secure - it is not a "256-bit DH group," and comparing it against the 2048-bit DH threshold is a category error.

Both provide forward secrecy. A server offering only ECDHE with modern curves is doing exactly the right thing - there is no DHE group left to be weak in the first place.

How to fix a weak TLS configuration

Do not hand-write a cipher list from memory, and do not paste a fixed snippet that will quietly go stale - the safe set of protocols and ciphers shifts over time as new weaknesses surface, and a config that was correct last year can flag today. Generate the configuration instead. A TLS configuration generator such as tlsref.org’s configurator produces a current, ready-to-paste config for your specific server software from a chosen security profile.

Set the profile to modern. The modern profile targets TLS 1.3 only, with AEAD ciphers and ephemeral key exchange throughout - the strongest posture, and the one SecRift rewards with a clean score across every dimension in this check. Only drop to the intermediate profile if you still have to serve clients that genuinely cannot do TLS 1.3, and treat that as a temporary compromise rather than the goal.

Because the generator tracks the current baseline, pointing your server at its modern output fixes protocol versions, weak ciphers, forward secrecy, and key-exchange strength in a single change - without pinning your config to advice that was only correct on the day it was written. Two findings sit outside the cipher list: TLS compression is off by default in current builds, so if it is flagged, look for an explicit override; and TLS 1.3 early data (0-RTT) is opt-in - leave it off unless your application is built to handle replay safely.

How SecRift checks TLS configuration

SecRift connects to your domain’s HTTPS endpoint on port 443 and runs a native enumeration - it measures what the server actually accepts rather than inferring anything from a version banner. Six scored findings come out of it:

• Protocol versions - flags TLS 1.0/1.1 as serious and SSLv2/SSLv3 as critical, rewards TLS 1.2 as the baseline and TLS 1.3 as the target.
• Weak cipher suites - flags RC4, 3DES, EXPORT, NULL, and anonymous suites, separating actively broken ciphers from weaker legacy ones.
• Forward secrecy - confirms every accepted suite below TLS 1.3 uses ephemeral (EC)DHE key exchange.
• Key-exchange strength - checks that negotiated DHE groups reach 2048 bits and ECDHE curves reach 256 bits, evaluated independently of each other.
• TLS compression - confirms compression is disabled, closing off CRIME.
• Early data - reports whether TLS 1.3 0-RTT is enabled, skipped entirely when the server does not offer TLS 1.3.

This sits alongside SecRift’s TLS vulnerabilities probes, which test for specific implementation bugs like Heartbleed and ROBOT rather than configuration choices - a server can pass every vulnerability probe while still running a weak configuration, and vice versa. On mail servers, the same transport-side hardening shows up behind SMTP TLS.

Run a free scan on any domain at secrift.com and see your TLS configuration posture in seconds.