TLS Configuration: Protocol Versions, Cipher Suites and What to Disable

TLS configuration is one of the few security tasks where the correct answer is short, well documented and still frequently got wrong — usually because a server was configured years ago and nobody revisited it.

Protocol versions

SSL 2.0 and 3.0 are long dead and must be disabled. TLS 1.0 and 1.1 are deprecated, removed from browsers, and disallowed by most compliance regimes.

TLS 1.2 remains widely required for compatibility and is acceptable when configured with modern cipher suites. TLS 1.3 is the current version and is a substantial simplification: it removes every weak option rather than making them configurable, mandates forward secrecy, encrypts more of the handshake, and completes in fewer round trips.

That design decision is the interesting one. TLS 1.2 is secure if configured correctly, and most vulnerabilities of the last decade exploited options it permitted. TLS 1.3 removes the ability to configure it wrongly, which is a stronger guarantee than documentation.

Enable 1.2 and 1.3; disable everything below.

Reading a cipher suite

A TLS 1.2 suite names four things: the key exchange, the authentication, the bulk cipher, and the message authentication algorithm — for example ECDHE for key exchange, RSA for authentication, AES-128-GCM for the data, and SHA-256 for integrity.

What to require: ECDHE for key exchange, because it provides forward secrecy and static RSA key transport does not. AEAD ciphers — AES-GCM or ChaCha20-Poly1305 — which combine encryption and authentication in one operation and avoid the padding oracle problems that dogged the older CBC constructions.

What to disable: RC4, 3DES, any export-grade suite, anything using MD5 or SHA-1 for integrity, static RSA key exchange, and anonymous suites that authenticate nothing.

TLS 1.3 simplifies this to a handful of suites naming only the cipher and hash, since key exchange and authentication are negotiated separately and only strong options exist.

Order and downgrade

Configure the server to enforce its own preference order rather than accepting the client's, so a client offering a weak suite first does not get it.

The broader pattern is downgrade: an attacker interferes with the handshake so both sides settle on the weakest mutually supported option, even though both support better. Several named attacks worked this way, and the general lesson recurs throughout security — a strong protocol with a weak fallback is as strong as the fallback, and the counter is always to remove the weak option rather than merely deprioritise it.

TLS 1.3 includes explicit downgrade protection in the handshake, and enforcing minimum versions server-side is what matters for 1.2.

Certificates and revocation

Serve the full chain including intermediates. A server omitting them produces the classic intermittent failure where browsers that cached the intermediate succeed and everything else fails — the chain validation described under PKI structure.

Enable OCSP stapling, where the server obtains a signed status for its own certificate and presents it during the handshake. That removes the client's separate lookup, which is faster, removes the privacy leak of clients querying the certificate authority, and removes the dependency on the responder being reachable at connection time. It is a single configuration line on most servers and is frequently left off.

Prefer ECDSA certificates where client support allows, since they are smaller and faster, and keep key sizes current — 2048-bit RSA as a minimum.

The headers that go with it

HSTS tells browsers to use HTTPS for a defined period, which prevents downgrade to plaintext and prevents users clicking through warnings once preloaded. Deploy with a short max-age first, verify nothing breaks, then increase — a long HSTS policy on a misconfigured site is difficult to undo.

Redirect HTTP to HTTPS, and set the security headers listed under web server hardening.

Testing and maintaining it

Test the configuration rather than assuming it, using an external assessment service or a command-line scanner that enumerates supported versions and suites and reports weak options. Do it after every change and periodically regardless, because a platform upgrade can silently re-enable something.

Monitor certificate expiry independently of whatever is meant to renew it, since expiry remains one of the most common self-inflicted outages — the point made under certificate lifecycle.

And remember that inspection appliances sit in this path. A proxy terminating TLS decides the cipher suite on the outbound leg, and a misconfigured one can present a clean connection to the client while negotiating something weak upstream — the failure noted under TLS proxies.

Exam angles

Know that SSL and TLS 1.0/1.1 must be disabled, TLS 1.2 is acceptable when configured correctly, and TLS 1.3 removes weak options by design and mandates forward secrecy. Read a cipher suite as key exchange, authentication, bulk cipher and MAC, requiring ECDHE and AEAD ciphers. Know downgrade attacks and that removing weak options is the counter. Identify OCSP stapling as the server presenting a signed revocation status, and HSTS as preventing plaintext downgrade.