TLS Cipher Suite Explorer
Explore and audit TLS cipher suites, algorithms, and strength levels.
TLS Cipher Suite Explorer
| Name | Protocol | Status | Key Exchange | Encryption |
|---|---|---|---|---|
| TLS_AES_256_GCM_SHA384 | TLS 1.3 | Secure | ECDHE | AES-GCM (256-bit) |
| TLS_CHACHA20_POLY1305_SHA256 | TLS 1.3 | Secure | ECDHE | ChaCha20-Poly1305 |
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | TLS 1.2 | Secure | ECDH | AES-GCM (128-bit) |
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 | TLS 1.2 | Weak | ECDH | AES-CBC (256-bit) |
| TLS_RSA_WITH_3DES_EDE_CBC_SHA | TLS 1.0 | Insecure | RSA | 3DES |
Runs entirely in your browser
This tool executes locally using standard browser APIs (for example window.crypto.getRandomValues or crypto.subtle where applicable). Your input is not transmitted to or stored on a ScriptPulse server. See How Calculations Work.
What This Tool Does
- The TLS Cipher Suite Explorer is a reference for the cipher suites TLS negotiates during a handshake — the combination of algorithms that determine how a connection performs key exchange, authentication, bulk encryption, and integrity protection. A cipher suite name like TLS_AES_256_GCM_SHA384 looks opaque at first, but each component identifies a specific algorithm choice, and knowing how to read that name is what lets you actually judge whether a given configuration is current best practice or a legacy holdover.
- TLS 1.3 (RFC 8446) meaningfully simplified this landscape compared to TLS 1.2 and earlier: it removed static RSA key exchange, all CBC-mode ciphers, and compression, and its cipher suite names describe only the bulk encryption and hash — key exchange and authentication are always ephemeral Diffie-Hellman plus a signature, negotiated separately, rather than baked into the suite name itself. This is why a TLS 1.3 suite name looks shorter than a TLS 1.2 one describing the same overall security level.
How It Works
- Each cipher suite entry decomposes a suite name into its component algorithms: key exchange (how the shared secret is established, e.g. ECDHE), authentication (how the server proves its identity, tied to the certificate's key type), bulk encryption (the cipher actually protecting the data, e.g. AES-GCM or ChaCha20-Poly1305), and MAC/AEAD (integrity protection).
- Suites are tagged by the TLS protocol version they belong to (TLS 1.0 through 1.3), since some ciphers were deprecated or removed entirely between versions.
- A status classification (Secure, Weak, Insecure) reflects current cryptographic guidance — for example, CBC-mode suites and 3DES are flagged as weaker or insecure relative to modern AEAD ciphers like AES-GCM and ChaCha20-Poly1305.
- The search filters the reference list by suite name or component, letting you quickly check whether a specific suite you've seen in a server configuration or scan report is current, deprecated, or actively insecure.
Usage
- Search or browse the cipher suite reference list.
- Read each suite's decomposed components — key exchange, authentication, bulk encryption, and MAC/AEAD.
- Check the status classification to understand whether a suite reflects current guidance or should be avoided.
- Cross-reference a suite name seen in your own server logs or a scanning tool's report against this reference to decide whether it needs attention.
Examples
- Looking up TLS_AES_256_GCM_SHA384 (a TLS 1.3 suite) to confirm it uses ECDHE key exchange implicitly and AES-256-GCM for authenticated encryption.
- Searching for '3DES' to identify legacy suites that should be disabled on a server still supporting TLS 1.0 for compatibility with very old clients.
- Comparing an ECDHE-based TLS 1.2 suite against a TLS 1.3 suite covering an equivalent security level, to understand the naming difference between the two protocol versions.
- Checking a CBC-mode suite's status classification after seeing it flagged in a security scan, to understand why AEAD ciphers are now preferred over CBC-mode constructions.
Real-World Use Cases
- Checking whether a cipher suite seen in a server's TLS configuration or a scanning tool's output (e.g. testssl.sh, Qualys SSL Labs) is current best practice or a legacy holdover that should be disabled.
- Understanding what each component of a cipher suite name actually means before deciding which suites to allow or disable in a server's TLS configuration.
- Comparing TLS 1.2 and TLS 1.3 suite naming to understand why TLS 1.3's suite list looks shorter despite offering an equivalent or stronger set of security properties.
- Auditing a legacy system's TLS configuration for suites using deprecated algorithms (RC4, 3DES, static RSA key exchange, CBC-mode ciphers) that should be disabled.
Best Practices
- Prefer TLS 1.3 where client support allows it — its simplified, ECDHE-only, AEAD-only suite set removes entire categories of historical TLS vulnerabilities by construction rather than requiring careful suite selection.
- When TLS 1.2 must still be supported, prioritize ECDHE key exchange (for forward secrecy) and AEAD ciphers (AES-GCM, ChaCha20-Poly1305) over CBC-mode suites.
- Disable static RSA key exchange and any suite using RC4 or 3DES — these are legacy choices with known weaknesses that current guidance no longer considers acceptable for new deployments.
- Periodically re-audit which cipher suites a server actually offers, since guidance on what's 'secure' evolves as new attacks are published and hardware makes older ciphers more practically breakable.
Common Mistakes
- Assuming a longer or more complex-looking cipher suite name is automatically stronger — TLS 1.3's shorter suite names reflect protocol simplification, not weaker security, since key exchange and authentication are always ECDHE-plus-signature and no longer part of the name.
- Leaving legacy suites (3DES, RC4, static RSA key exchange) enabled for broad compatibility long after the clients that actually needed them have been retired.
- Treating 'uses AES' as sufficient evidence a suite is current — the mode matters as much as the cipher: AES-CBC is now considered weaker than AES-GCM for TLS use, despite both using the same underlying block cipher.
- Confusing the cipher suite negotiated with the TLS protocol version itself — a modern protocol version can still be configured to allow a weak suite unless it's explicitly disabled.
Limitations
- This is a reference and lookup tool over a fixed, illustrative set of cipher suites; it does not scan or connect to any live server to determine what it actually negotiates.
- Security classifications reflect general current guidance and can change as cryptanalysis advances — always cross-check against your own organization's current security policy for authoritative requirements.
- It does not configure a server directly; use the information here to inform your own TLS configuration changes in whatever server software you're running.
Technical Reference Guide
- TLS 1.3, including its simplified cipher suite structure (bulk cipher and hash only, no separate key exchange/authentication component in the name), is defined by RFC 8446.
- TLS 1.2's cipher suite structure, including the older CBC-mode and static-RSA suites it permitted, is defined by RFC 5246 (now obsoleted by TLS 1.3 for new deployments, but still relevant for understanding legacy configurations).
- The full registry of assigned cipher suite names and their numeric identifiers is maintained by IANA's TLS Cipher Suites registry, the authoritative source for what a given suite name actually refers to.
FAQ
Why do TLS 1.3 cipher suite names look shorter than TLS 1.2 ones?
TLS 1.3 always uses ephemeral Diffie-Hellman key exchange with a separately-negotiated signature for authentication, so suite names only need to specify the bulk cipher and hash. TLS 1.2 suite names spelled out key exchange and authentication explicitly because those varied per suite.
Is AES-CBC insecure?
It's not broken outright, but it's considered weaker than AES-GCM or ChaCha20-Poly1305 for TLS specifically, due to padding-oracle-style attacks (like Lucky 13) that have affected CBC-mode TLS implementations historically. Current guidance prefers AEAD ciphers.
Should I still support TLS 1.0 or 1.1 for compatibility?
Generally no — both are deprecated by the IETF and major browsers have removed support. Supporting them mainly extends the life of the exact legacy cipher suites that current guidance recommends disabling.
What does 'forward secrecy' mean, and which suites provide it?
Forward secrecy means a compromised long-term private key can't be used to decrypt previously-captured traffic. Suites using ephemeral Diffie-Hellman (ECDHE, or DHE) provide it; suites using static RSA key exchange do not.
Does this tool tell me what cipher suites my own server actually supports?
No — it's a reference for understanding suite names and current guidance. Use a dedicated scanning tool (such as testssl.sh or an online SSL Labs-style scanner) against your own server to see what it actually negotiates.
What's the difference between AES-GCM and ChaCha20-Poly1305?
Both are modern AEAD (authenticated encryption) ciphers considered secure choices for TLS 1.2 and 1.3. AES-GCM benefits from hardware acceleration on most modern CPUs; ChaCha20-Poly1305 was designed to perform well even without that hardware support, which matters more on mobile and lower-power devices.
Part of this Developer Hub
This utility is part of our comprehensive Certificate & PKI topic workspace.
Explore foundational guidelines, technical specifications, and other interactive utilities related to this workflow.
Related Tools
Explore related utilities inside the Certificate & PKI Lab workshop for complementary engineering workflows.
View all Certificate & PKI Lab tools