A cipher suite is the specific combination of algorithms a browser and server agree to use for a given TLS connection — covering key exchange, authentication, bulk encryption, and integrity checking. When an SSL scan tool reports something like TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, it looks dense, but each segment names one specific job.
The four jobs inside every cipher suite
- Key exchange (e.g. ECDHE, DHE) — how the browser and server agree on a shared secret. Modern suites use ephemeral (temporary) key exchange, which is what provides Perfect Forward Secrecy.
- Authentication (e.g. RSA, ECDSA) — the algorithm used to verify the server's certificate signature, proving the server is who it claims to be.
- Bulk encryption (e.g. AES_256_GCM, CHACHA20_POLY1305) — the actual cipher used to encrypt the page content, form data, and everything else exchanged after the handshake.
- Integrity / MAC (e.g. SHA384) — confirms data wasn't tampered with in transit; in modern AEAD ciphers like GCM, this is often built into the encryption mode itself rather than a fully separate step.
Why some cipher suites are considered weak or broken
Older suites used algorithms that have since been broken or significantly weakened by advances in cryptanalysis and computing power — RC4 (broken), 3DES (weak, vulnerable to the Sweet32 attack), and non-ephemeral RSA key exchange (no forward secrecy) are the most commonly flagged examples. An SSL scan tool grading your server will specifically call these out, because supporting them at all, even alongside strong ones, gives an attacker room to force a downgrade to the weaker option during the handshake.
How cipher suite negotiation actually happens
During the ClientHello step of the handshake, the browser sends an ordered list of cipher suites it supports, from most to least preferred. The server picks one — typically its own most-preferred suite that the browser also supports — and that becomes the suite used for the entire session. Server-side configuration controls which suites are offered at all and in what priority order, which is exactly what you're editing when you harden a server's TLS configuration.
TLS 1.3 simplified this considerably
TLS 1.3 dramatically shrank the list of allowed cipher suites — down to five, all using AEAD encryption modes and mandatory forward secrecy — removing the ability to even negotiate the weaker, legacy combinations that caused so many historical vulnerabilities in TLS 1.2 and earlier. If your server supports TLS 1.3, cipher suite hardening for that protocol version is largely already handled by the protocol design itself, rather than requiring manual configuration.
Checking your own server's cipher suite support
An SSL scan tool (like Qualys SSL Labs' SSL Server Test) will list every cipher suite your server currently offers, flag any considered weak, and assign an overall letter grade. This is the fastest way to see exactly what you're supporting without manually parsing your web server's TLS configuration file.
TLS 1.3's cipher suite list, in full
Where TLS 1.2 allows dozens of possible suite combinations (which is part of why misconfiguration was so common), TLS 1.3 narrows the field to five, all modern and all using authenticated encryption: TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_GCM_SHA256, TLS_AES_128_CCM_8_SHA256, and TLS_AES_128_CCM_SHA256. Notice these names are shorter than TLS 1.2 cipher suite names — they no longer specify a key exchange or authentication algorithm at all, because TLS 1.3 negotiates those separately, always using forward-secret key exchange by design rather than encoding it into the suite name.
Disabling weak cipher suites on your own server
Most web servers let you explicitly define an allowed cipher suite string rather than trusting the platform defaults, which matters because older operating systems sometimes ship with legacy suites still enabled for backward compatibility. On Nginx, this is controlled with the ssl_ciphers directive; on Apache, SSLCipherSuite. Rather than hand-writing this list from scratch, use a current, actively maintained reference — Mozilla's SSL Configuration Generator produces a ready-to-use configuration block for several server platforms, offering "modern," "intermediate," and "old" presets depending on how much legacy client compatibility you actually need to preserve.
Why a mismatch causes a hard failure, not a warning
If a client and server share no cipher suite in common at all, the handshake fails outright with a connection error, rather than a certificate warning a visitor could click through — because at that point, no certificate has even been exchanged yet. This most commonly shows up when a very old client (an outdated device, or an old API integration library) hits a server that's been hardened to only offer modern suites, and is a useful diagnostic signal in its own right: a hard TLS handshake failure with no certificate details visible generally means a protocol or cipher suite mismatch, not a certificate problem.
Why you almost never need to hand-pick individual suites
For the overwhelming majority of site owners, manually selecting individual cipher suites is unnecessary and even risky if done without deep expertise — using a current, well-maintained configuration preset (Mozilla's SSL Configuration Generator is the standard reference) achieves a strong, current baseline without needing to track ongoing cryptanalysis research yourself.
How to actually read your own server's current configuration
Running an SSL scan tool against your domain will list every cipher suite your server currently offers, in the order it prefers them, along with an overall grade — this is the fastest, most reliable way to see exactly what you're supporting without manually parsing your web server's configuration file line by line.
Why a hard handshake failure often means a cipher mismatch, not a cert problem
If a client and server share no cipher suite in common at all, the handshake fails outright with a connection error rather than a certificate warning, since no certificate has even been exchanged yet at that point. This is a genuinely useful diagnostic signal: a hard failure with no certificate details visible usually points to a protocol or cipher mismatch, not anything wrong with the certificate itself.
TLS 1.3's five-suite list, and why it's shorter is a feature
Where TLS 1.2 allows dozens of possible combinations, which is part of why misconfiguration was so common, TLS 1.3 narrows the field to five modern, uniformly strong options — none of them requiring the same kind of manual vetting older TLS 1.2 suite lists demanded, since every option TLS 1.3 offers is already considered current best practice by design.
A cipher suite name looks dense at first glance, but once you know the four jobs, key exchange, authentication, encryption, integrity, every suite name becomes readable rather than an opaque string to memorize.
A quick closing checklist for a healthy cipher suite configuration
Confirm only TLS 1.2 and 1.3 are enabled, every offered suite uses an AEAD cipher, and forward secrecy is universal across your configuration — three checks an SSL scan tool will confirm directly.