Short answer
A cipher suite is the named combination of cryptographic algorithms that client and server agree to use for a single TLS connection. It fixes four things: how they agree on a shared key (key exchange), how the server proves its identity (authentication), how the traffic itself is encrypted (cipher), and how integrity is protected (MAC/hash). The name encodes each part — once you can read the order, you can decode any suite.
The four jobs a cipher suite covers
- Key exchange: How client and server agree on a shared secret without sending it in clear text — typically ECDHE.
- Authentication: How the server proves it is who it claims to be — via the certificate's key type, RSA or ECDSA.
- Bulk encryption: Which symmetric cipher encrypts the actual data traffic — e.g. AES-GCM or ChaCha20-Poly1305.
- Message authentication (MAC): Which hash ensures the data was not tampered with in transit — e.g. SHA-256.
The TLS 1.2 name decoded
Take a classic TLS 1.2 suite in OpenSSL's notation:
ECDHE-RSA-AES256-GCM-SHA384 │ │ │ │ │ │ │ │ │ └─ SHA384 — hash for key derivation (PRF/HKDF) │ │ │ └─────── GCM — encryption mode (AEAD) │ │ └────────────── AES256 — symmetric cipher, 256-bit key │ └──────────────────── RSA — authentication (certificate key type) └────────────────────────── ECDHE — key exchange (ephemeral, gives forward secrecy)
In IANA's official notation the exact same suite is called TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. It is the same thing — just two different ways of writing precisely the same algorithm bundle.
The TLS 1.3 name is much shorter
TLS 1.3 removed the weak options and standardised key exchange and authentication, so they no longer need to appear in the name. What remains is just cipher + hash:
TLS_AES_128_GCM_SHA256 │ │ │ │ │ │ │ └─ SHA256 — hash for HKDF │ │ └───── GCM — AEAD mode │ └───────────── AES_128 — symmetric cipher, 128-bit key └───────────────── TLS — fixed prefix # The five standardised TLS 1.3 suites: TLS_AES_128_GCM_SHA256 TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_CCM_SHA256 TLS_AES_128_CCM_8_SHA256
In TLS 1.3 key exchange (always ephemeral ECDHE or DHE) and the signature algorithm are negotiated separately from the cipher suite. That is why there are only five suites — versus hundreds in TLS 1.2 — and none of them is insecure. The negotiation happens as part of the TLS handshake.
See which ciphers your OpenSSL knows
The list is long. Filter to the modern high-security ones:
openssl ciphers -v 'ECDHE+AESGCM:ECDHE+CHACHA20' | column -t
Each line shows the suite name, minimum protocol, key exchange (Kx=), authentication (Au=), cipher (Enc=) and MAC (Mac=) — exactly the four jobs above.
See what a server actually offers
nmap --script ssl-enum-ciphers -p 443 example.com
The output groups suites per protocol version and gives each a letter grade (A–F). Any C or worse — or a suite without ECDHE — is worth a closer look. To test more deeply, see our guide to testing TLS ciphers.
What is a "good" cipher suite today?
A healthy modern suite has: ephemeral key exchange (ECDHE) for forward secrecy, an AEAD cipher (GCM or POLY1305, not CBC), and a SHA-2 hash. Suites with RC4, 3DES, CBC, MD5, SHA1 or static RSA key exchange without ECDHE should be turned off. We walk through the recommended list in the best TLS cipher suites and the dangerous ones in why RC4 and 3DES are dangerous.
How CertControl keeps track of this
Cipher configuration drifts — a hardening pass is forgotten on one server, a load balancer image rolls back to an old default. CertControl probes your endpoints from the outside, records which cipher suites and protocol versions each server actually accepts, and raises findings with severity when a weak or outdated suite appears. So you see the deviation at the next scan rather than in an audit report.
Frequently asked questions
What is the difference between a cipher and a cipher suite?
A cipher is one algorithm — e.g. AES, which encrypts data. A cipher suite is the whole bundle of algorithms for a TLS connection: key exchange, authentication, cipher and MAC together. The suite name describes all the parts.
Why are TLS 1.3 names so much shorter than TLS 1.2?
Because TLS 1.3 removed the weak options and moved key exchange and authentication out of the cipher suite negotiation itself. What remains is just the symmetric cipher and hash, so the name only needs those two parts.
What does ECDHE at the start of the name mean?
ECDHE is the key exchange method: Elliptic Curve Diffie-Hellman Ephemeral. "Ephemeral" means a new key is used per session, which provides forward secrecy — old traffic cannot be decrypted even if the server's private key later leaks.
Is AES-128 less secure than AES-256?
In practice both are far more than secure enough. AES-128 has no practical attacks and is faster. AES-256 gives a larger security margin and is often required by compliance regimes, but there is no known real weakness in AES-128 for ordinary use.
How do client and server choose which suite to use?
The client sends a list of the suites it supports in preference order. The server picks the first one from its own allowed list that matches. With server preference enabled, the server's order wins — so the server configuration effectively controls the result.
Do I need to choose cipher suites manually?
On modern systems only to remove outdated suites. A good rule is to follow Mozilla's "intermediate" recommendation as a baseline and only move to "modern" if all your clients support TLS 1.3.