Report

Help us improve this tool

TLS Cipher Suite Explainer

Break down IANA TLS cipher suite strings into key exchange, authentication, encryption, and MAC components.

O M T

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.