Weak cipher suites

The client sends the list of suites it supports, in its own order of preference.

The server picks one, either honouring the client's preference or imposing its own.

A server that honours client preference will use a weak suite whenever a client asks for one first, which is why server-side preference ordering was long considered important.

The current TLS version changed the negotiation and removed the suites that made this dangerous, so the ordering question largely disappeared with it.

Which means a server offering only the current version has very little to configure here, and one still offering older versions has a real decision.

A key exchange without forward secrecy, which lets recorded traffic be decrypted later if the server key is ever obtained.

An obsolete bulk cipher, including stream ciphers and block ciphers with known structural problems.

A weak or absent authentication component, including the export-grade suites that exist only as historical artefacts.

An obsolete hash in the message authentication, which weakens integrity rather than confidentiality.

A suite can be weak in one of these dimensions and sound in the others, which is why the assessment is per suite rather than per algorithm.

The current TLS version defines a small set of suites, all of which provide forward secrecy and modern ciphers.

The previous version supports a much larger set including everything obsolete, which is where the weak options come from.

So disabling the older versions removes most weak suites as a consequence, without configuring suite lists at all.

The versions before that are obsolete outright and their continued support is a separate and more serious finding.

Which makes the practical order: disable obsolete versions first, then tidy the suite list on whatever older version you still need.

Very old clients. The question is always which ones, and the honest answer for most sites is none that matter.

Some payment terminals, embedded devices and legacy integrations remain on older versions, and those are the real constraint where they exist.

Analytics on the older protocol versions tells you who is actually connecting, which is a better basis than assumption.

Compliance regimes frequently mandate a floor, which settles the question externally for sites subject to one.

A staged approach — disable the obsolete versions, watch for a period, then tighten suites — costs little and avoids surprises.

`openssl s_client -connect example.com:443 -tls1_2` and similar for each version shows which the server accepts.

The handshake output names the negotiated suite, which is what the server chose for that client.

Testing with one client tells you what that client got, not what the server offers — enumerating requires a tool built for it.

Check every hostname separately, since a load balancer and an origin can differ, as can two hostnames on the same platform.

Re-check after any change to the termination layer, which is where the configuration usually lives.

`transport.cipher_suites` reports the suites really observed on the connection, which is this problem directly.

`transport.tls_versions` reports the protocol versions accepted, which is what decides most of the outcome.

`transport.certificate_details` reports the certificate and its key, which is a separate dimension of the same handshake.

`transport.https` establishes that HTTPS works at all before any of this applies.

A server offering only the current protocol version is reported as such rather than as having a short suite list, because the two statements mean different things.

On most sites TLS is terminated before the application — at a load balancer, a reverse proxy or a CDN edge — and the suite list belongs to whichever of those answers.

Which means editing the application server's configuration frequently changes nothing observable, because the connection never reached it.

A CDN generally offers a small set of named policies rather than a suite list, which is a simpler and usually better-maintained choice than a handwritten one.

Where the origin is also directly reachable, it needs its own configuration: an origin left on defaults is the weak path nobody tested.

Testing from outside against each hostname is what reveals which layer actually answered, since the configurations are independent.