Cipher Ranking

Analyze and rank supported cipher suites

Domain

Port

Results

About

The Cipher Suite Ranking tool analyzes and ranks the TLS cipher suites supported by your server, scoring them based on security strength, performance, and modern cryptographic best practices. It evaluates each cipher suite across multiple dimensions — key exchange algorithm, authentication method, bulk encryption strength, and MAC algorithm — to provide an overall security grade.

The ranking helps you identify weak cipher suites that should be disabled, understand the security implications of your cipher ordering, and optimize your configuration for the best balance of security and performance. It also highlights support for forward secrecy ciphers (ECDHE, DHE) and flags known-vulnerable ciphers like RC4, 3DES, and export-grade algorithms.

How to Use

1Enter the domain name you want to analyze (e.g., example.com)
2Optionally specify a custom port number (default 443)
3Click "Rank Ciphers" to analyze all supported cipher suites
4Review the ranked list showing security scores, cipher details, and recommendations

Use Cases

•Security Hardening: Identify and disable weak cipher suites to meet security standards like NIST SP 800-52 and PCI DSS
•Compliance Validation: Verify cipher suite configuration meets regulatory requirements for encryption strength
•Performance Optimization: Order cipher suites to prefer faster, more secure options like AES-GCM and ChaCha20-Poly1305
•Vulnerability Assessment: Detect support for known-vulnerable ciphers (RC4, 3DES, EXPORT, NULL) that could be exploited
•Migration Planning: Plan cipher suite updates when transitioning from legacy configurations to modern TLS best practices

How Suites Are Ranked

Ranking suites means ordering them by properties that actually matter, not by an arbitrary preference. This page sorts on exactly those.

1Order by cipher strength first, since that is the primary protection. AEAD suites with AES or ChaCha20 rank above CBC suites, which sit above the broken constructions with no real confidentiality at all.
2Break ties with forward secrecy. Among equally strong suites, those providing ephemeral key exchange rank higher, because that is what limits the damage from a future key compromise.
3Show the best and the worst a server offers, alongside the full ordering. The weakest suite present matters more than the strongest — it is what a downgrade-capable attacker would aim for.

Ranking is a judgement about suites in the abstract. Which one your connections actually use depends on both ends, which is why the ordering here pairs with the cipher-order page that offers suites individually to a live server.

Tips & Best Practices

•Prioritize cipher suites with ECDHE key exchange for forward secrecy
•Prefer AES-GCM and ChaCha20-Poly1305 over AES-CBC for better performance and security
•Disable all NULL, EXPORT, RC4, DES, and 3DES cipher suites immediately
•Order server cipher suites to prefer TLS 1.3 ciphers over TLS 1.2 when both are supported

Technical Details

●Scoring Algorithm: Weighted scoring based on key exchange (30%), authentication (20%), encryption (30%), and MAC (20%)

●Forward Secrecy: Detects and prioritizes ECDHE and DHE key exchange methods

●Cipher Categories: Classifies ciphers as Secure, Acceptable, Weak, or Insecure based on current standards

●Client Compatibility: Reports which cipher suites are required for compatibility with older clients

Frequently Asked Questions

A strong cipher suite uses secure components: ECDHE or DHE for forward secrecy, ECDSA or RSA for authentication, AES-128/256-GCM or ChaCha20-Poly1305 for encryption, and SHA-256 or SHA-384 for MAC. The overall strength depends on the weakest component — a strong cipher suite must have strong options in all four areas.

It depends on your client base. If you only need to support modern browsers (Chrome 70+, Firefox 63+, Safari 12+), you can safely disable TLS 1.0/1.1 and all legacy ciphers. If you need to support older clients, keep TLS 1.2 with AES-CBC ciphers but ensure RC4, 3DES, and EXPORT are disabled.

Cipher ordering determines which cipher suite the client and server will negotiate during the TLS handshake. The server's first mutually supported cipher is typically chosen, so placing your strongest, most secure cipher suites first ensures they are preferred. Poor ordering may result in negotiating weaker ciphers unnecessarily.

Because an attacker who can influence the handshake will aim for the weakest option available. A server offering excellent suites alongside a broken one has not mitigated anything — the broken one is a target, and finding a way to make a client choose it is the attack. The strongest suite matters only to clients that cannot be steered, which is not something to rely on.

In most cases yes, and it is a small change with a clear rationale. If the client controls the order, a client with an unusual preference can cause a weaker suite to be selected even though the server supports better ones. Preferring server-side removes that influence. It matters less on TLS 1.3, where clients cannot control selection the same way, but it remains relevant on 1.2.

Take the top few suites from the list and configure those, then remove the weak ones rather than merely ranking them lower. Ordering a weak suite last does not remove it — it stays negotiable, and a downgrade attempt reaches it. Configuration and ordering are separate controls and both are needed.

No, and the distinction matters. This page ranks suites by their properties, which is a judgement about cryptography. What a specific server will actually negotiate depends on its configuration and on the client, which is what the cipher-order and cipher pages measure. Use this list to decide what to prefer and those to confirm what happens.

Because 1.3 offers only four, all AEAD and all forward-secret, so the ordering between them reflects cipher strength rather than any difference in structural properties. That uniformity is the point — a large part of TLS's configuration complexity is a 1.2-era problem that the newer protocol does not have.