Cipher Suite Checker

Test which SSL/TLS cipher suites a server supports

About Cipher Suites

A cipher suite is a set of cryptographic algorithms used to secure a TLS connection, including key exchange, authentication, encryption, and message authentication code methods. Our Cipher Suite Checker tests which cipher suites a server supports, grades their strength, checks for forward secrecy (PFS), and verifies TLS 1.3 compatibility to help you maintain a secure and modern TLS configuration.

How to Use

Enter the domain name of the server you want to test.
Click Check Ciphers to scan the server's supported cipher suites.
Review the overall grade, number of supported ciphers, and TLS 1.3 status.
Check individual cipher grades and identify weak or deprecated ciphers to disable.

Use Cases

Security Hardening: Identify and disable weak or deprecated cipher suites on your server.
Compliance Auditing: Verify that your TLS configuration meets PCI DSS, HIPAA, or other regulatory requirements.
Forward Secrecy Verification: Confirm that your server supports PFS ciphers for enhanced security.
Upgrade Planning: Check if your server supports TLS 1.3 before planning an upgrade from older protocols.

Frequently Asked Questions

Forward secrecy (also called Perfect Forward Secrecy or PFS) ensures that session keys are not compromised even if the server's private key is exposed. It uses ephemeral key exchange algorithms like ECDHE or DHE. Servers supporting PFS ciphers provide stronger protection for past communications.

You should disable all cipher suites using RC4, DES, 3DES, IDEA, and SEED encryption. Also disable all EXPORT-grade ciphers and those using anonymous Diffie-Hellman (aNULL). Only enable cipher suites with AEAD encryption like AES-GCM or ChaCha20-Poly1305 for modern security.

TLS 1.3 is the latest TLS protocol version that removes legacy and insecure features, reduces handshake latency to one round trip (or zero for resumed connections), requires forward secrecy for all ciphers, and simplifies the cipher suite list. It provides significant security and performance improvements over TLS 1.2 and earlier.

Because the overall grade reflects every suite offered, not the one you happened to negotiate. A downgrade-capable attacker can force a client into a weaker suite if the server still accepts it, so the weakest suite reachable determines the real exposure. Offering strong suites alongside weak ones is not a safe configuration — remove the weak ones so there is nowhere to be pushed.

Sweet32. Its 64-bit block size means a birthday collision becomes practical after enough blocks of data, which for a long-lived connection carrying a lot of traffic is reachable, and the collision reveals plaintext. That makes 3DES unsuitable for anything except legacy interoperation, which is the opposite of how it was regarded when it was introduced.

Strong describes the cipher construction; forward secrecy describes the key exchange. A suite can be strong and still lack forward secrecy — RSA key exchange with AES-GCM is exactly that case: excellent confidentiality for the session, but a later compromise of the private key decrypts everything recorded. Both properties matter, and this page tracks them separately because improving one does not fix the other.

Worse than they look, and worse than most people assume. They are exposed to padding-oracle attacks — POODLE, Lucky 13 and their relatives — which recover plaintext from an error response revealing only whether padding was valid. That requires an attacker who can induce chosen requests and observe responses, so it is not a drive-by risk, but the fix is trivial: prefer AEAD suites, which are available on every current client.

Effectively no, which is one of its quieter benefits. The protocol defines only four suites, all AEAD, all forward-secret, and removes the ability to negotiate anything weaker. Any configuration complexity in cipher selection is a 1.2-and-below problem, and moving to 1.3 retires the whole category.

How Suites Are Graded

Every cipher suite this page reports is classified on two axes that matter separately: how strong the construction is, and whether it provides forward secrecy.

1Reject the outright broken first: null, export and anonymous suites provide no real confidentiality, and RC4 and single-DES are cryptographically broken. These are graded F regardless of anything else about them.
2Then the weak and the acceptable. 3DES is graded D for its small block size, which enables birthday attacks on long connections. CBC suites with a SHA MAC are graded B — functional but exposed to padding-oracle attacks, which is why they are a step down from AEAD rather than a failure.
3Award the top grade to AEAD: anything with GCM or ChaCha20 is graded A, and every TLS 1.3 suite is A by definition since the protocol offers nothing weaker. Forward secrecy is tracked separately, because a suite can be strong and still lack it.

The overall grade reflects the whole set offered, not the best one: a server offering only A-grade suites alongside one D-grade suite is graded D overall, because an attacker with a downgrade path has somewhere to go even though your connection chose well.

Tips & Best Practices

•Analyze cipher suite composition to understand security properties
•Use cipher suite analysis when creating server configurations
•Monitor cipher suite changes that may indicate security issues
•Compare cipher suites across servers for consistency

Technical Details

Analysis: Cipher suite component breakdown (key exchange, encryption, MAC)
Components: ECDHE, DHE, AES, ChaCha20, SHA, GCM, CBC analysis
Security: Security rating for each cipher suite component
Output: Cipher suite breakdown with security assessment