Does supporting more cipher suites improve compatibility without cost?

Does supporting more cipher suites improve compatibility without cost?

The operations instinct "enable every cipher suite so nothing breaks" treats the suite list as free insurance. It is not. In TLS 1.2 a long, permissive list reintroduces downgrade exposure: a network attacker who can influence negotiation steers the connection toward the weakest mutually supported option. The historical attacks — FREAK (forced export-grade RSA), Logjam (export-grade Diffie-Hellman), Sweet32 (64-bit block ciphers like 3DES) — all exploited suites that servers kept enabled "for compatibility" with clients that no longer existed.

The correct posture is an intentional, ordered allow-list with the server choosing, not the client. Mozilla's widely cited "intermediate" configuration enables a small set of AEAD (Authenticated Encryption with Associated Data) suites — AES-GCM and ChaCha20-Poly1305 — and nothing else. Real-world telemetry shows this covers essentially all clients from the last decade.

TLS 1.3 ended the debate by design: it defines only five AEAD cipher suites and removed renegotiation, static RSA, and CBC modes entirely (RFC 8446, §B.4). There is nothing weak left to enable.

— Long 1.2 lists invite downgrade attacks
— Server-chosen, ordered allow-list is the fix
— TLS 1.3 ships five safe suites, no knobs

Further reading: RFC 8446 §B.4; Mozilla SSL Configuration Generator.
Bottom line: More cipher suites means more attack surface, not more safety. Curate a short AEAD-only list.