TLS/SSL

Weak ciphers explained: RC4, 3DES, and why 'it still works' is not safe

A working padlock is not the same as strong encryption

When a TLS scan flags a weak cipher, the common reaction is reasonable confusion: the site loads over HTTPS, the browser shows a padlock, nothing is broken. All true. The catch is that the padlock only tells you the connection was encrypted — not how well. A cipher is the actual algorithm doing the encrypting, and your server can still be offering ones that stopped being safe years ago.

What a cipher is, briefly

When a browser connects over HTTPS, it and your server negotiate a cipher suite — the specific set of algorithms used to encrypt the traffic and verify integrity. Your server advertises a list of suites it supports; the browser picks one. If your list still includes old, broken algorithms, a connection can end up using one, and some clients will happily do so.

The usual suspects

  • RC4. An old stream cipher with known statistical biases that let parts of the encrypted traffic be recovered. It is considered broken and was formally prohibited years ago. There is no safe way to keep offering it.
  • 3DES. Not broken in the same dramatic way, but obsolete: it works on small 64-bit blocks, which exposes it to birthday-style attacks on long-lived connections, and it is slow. Modern guidance is to retire it.
  • Export-grade and NULL ciphers. Relics with deliberately weak or absent encryption. They should never be present.

Why 'it still works' is the trap

Weak ciphers are dangerous precisely because they are invisible in normal use. Nothing warns you. The site looks identical to one configured perfectly. The risk only shows up when someone who can sit between a user and your server downgrades the connection to the weakest option you allow — and then the encryption you were relying on is no longer doing its job. You don't notice because, to you, it always just worked.

The fix is a server-side allowlist

This is a configuration change, not a code change:

  • Offer only TLS 1.2 and TLS 1.3. Disable SSL 3.0, TLS 1.0 and TLS 1.1 entirely.
  • Remove RC4, 3DES, export and NULL suites from your accepted cipher list.
  • Prefer modern suites built on AES-GCM and ChaCha20-Poly1305, with forward secrecy.
  • Let your platform help. Many hosts and load balancers offer a 'modern' or 'intermediate' TLS policy you can simply select instead of hand-tuning a list.

If you are on managed hosting or a CDN, this is often a single dropdown. If you terminate TLS yourself, it is a few lines in your server config.

Check what your server offers

You cannot tell which ciphers your server accepts by visiting the site — the negotiation happens before the page loads. An automated scan inspects your TLS configuration and reports any weak protocols or ciphers still on offer. Scan your site and see your TLS posture.

Related reading

FAQ

If HTTPS works, why does a weak cipher matter?
Because HTTPS only proves the connection was encrypted, not that it was encrypted well. If your server still offers a broken cipher like RC4, a connection can be downgraded to it, weakening the protection you assumed was solid.
Is 3DES actually broken?
Not as catastrophically as RC4, but it is obsolete. Its small block size exposes it to practical attacks on long-lived connections, and it is slow. Current guidance is to disable it in favor of modern AES-GCM or ChaCha20 suites.
How do I disable weak ciphers?
It is a server configuration change. On managed hosting or a CDN it is often a single TLS policy setting; on your own server it is a few config lines limiting protocols to TLS 1.2 and 1.3 and removing old cipher suites.