TLS Cipher Suite Explainer
Break down IANA TLS cipher suite strings into key exchange, authentication, encryption, and MAC components.
Decode TLS cipher suite names
Server scans, openssl ciphers output, and load-balancer configs list
opaque identifiers such as
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. This explainer maps IANA-style
names to key exchange, authentication,
bulk encryption, and MAC/PRF roles, and calls
out whether forward secrecy is expected for TLS 1.2 suites.
TLS 1.2 vs TLS 1.3
TLS 1.2 names use the TLS_…_WITH_… pattern. TLS 1.3 suites are
shorter (TLS_AES_256_GCM_SHA384) because key exchange is negotiated in
the handshake and ciphers are AEAD-only. The trailing hash names the HKDF hash
function in TLS 1.3.
Pair with Security Headers Auditor when hardening HTTPS, and TLS RPT Record Builder for SMTP TLS reporting DNS records.
Frequently Asked Questions
Does this validate that a cipher is enabled on my server?
No. It only explains the name. Use your TLS stack or an external scanner to see what is actually negotiated.
Are legacy suites flagged?
Descriptions note deprecated algorithms (RC4, MD5, anonymous DH) when they appear in the token map. Always prefer modern AEAD suites in production.
Where do the names come from?
Strings follow the IANA TLS cipher suite registry conventions used by OpenSSL, BoringSSL, and most server documentation.