Cipher Order Checker

Check preferred cipher order and server cipher preference

About Cipher Order

The cipher suite order on a TLS server determines which encryption algorithms are preferred during the TLS handshake. Servers with strict cipher preference enforce their own ordering, ensuring the strongest ciphers are used. Our Cipher Order Checker connects to any TLS server and reveals the advertised cipher order, server preference setting, and which ciphers are considered secure.

How to Use

Enter the server domain name you want to analyze.
Specify the port (default 443 for HTTPS, but you can check other TLS-enabled ports).
Click Check to initiate the cipher order analysis.
Review the ordered list of cipher suites and the server's cipher preference setting.

Use Cases

Security Hardening: Verify your server prioritizes strong AEAD ciphers over weak or deprecated ones.
Compliance Checks: Ensure cipher order meets PCI DSS, HIPAA, or other regulatory requirements.
Server Configuration Audit: Identify misconfigured servers that allow weak cipher negotiation.
Penetration Testing: Include cipher order analysis in your security assessment toolkit.

Frequently Asked Questions

Server cipher preference (also called "server cipher ordering") means the server dictates which cipher suite is used, rather than letting the client choose. This is a security best practice because clients may prioritize weaker ciphers for compatibility.

Modern security best practices recommend prioritizing TLS 1.3 cipher suites, followed by AEAD ciphers like TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384. Avoid deprecated ciphers like RC4, 3DES, and CBC-mode ciphers.

For Nginx, use the ssl_ciphers directive and set ssl_prefer_server_ciphers on;. For Apache, use the SSLCipherSuite directive and SSLHonorCipherOrder On. Consult your server documentation for exact syntax.

Because a single handshake cannot reveal it. Server preference shows up only when the same suites are offered in different orders and the server's choice changes or stays fixed — which needs several deliberate handshakes this probe does not make. An earlier version returned the one negotiated suite as the order and reported server preference as true; both were invented, so this page reports what was genuinely accepted instead and states plainly that preference is undetermined.

Which suites the server will complete a handshake with, tested one at a time under TLS 1.2. That is more useful than a negotiated suite because it reveals the legacy options still open: if RSA key exchange or CBC suites appear alongside the modern ones, an attacker with a downgrade path has somewhere to go even though your own connection chose well.

Because in TLS 1.3 the client cannot choose individual suites the same way — the protocol removed client-controlled cipher selection as part of simplifying negotiation. Pinning each probe to 1.2 is the only way to ask the server a question about one specific suite. The initial default handshake still shows what a modern client negotiates, typically a 1.3 suite.

Only if weak ones are among them. A server accepting several modern suites is normal and healthy — clients differ in what they support. The concern is specific legacy entries: RSA key exchange without ephemeral keys removes forward secrecy, and CBC suites reintroduce padding-oracle risk. Count those, not the total.

With several handshakes offering the same suite set in deliberately reversed orders, comparing which suite the server selects each time. If the choice stays fixed regardless of your ordering, the server is imposing its own preference. openssl s_client with cipher list ordering is the practical way to do it, and the TLS 1.3 equivalent is checking whether the server honours the ordering it publishes.

What the Probe Measures

Cipher ordering is a claim about preference, and preference is only visible across several handshakes. This page separates what it can establish from what it cannot.

1Record what one handshake negotiated with default client preferences. That is a real observation, and it is labelled as the negotiated suite rather than as a preference order.
2Then offer five suites individually, each in its own TLS 1.2 handshake pinned to that one suite. The ones that complete are genuinely accepted by the server, which is a far more informative answer than a single negotiation. The accepted list is what this page reports as its cipher list.
3Flag legacy acceptance when RSA key exchange or CBC suites appear among the accepted, since those lack forward secrecy or expose the Lucky 13 class of attack.

Server preference is reported as not determined, deliberately. An earlier version returned it as true from a single handshake, which is unprovable: honouring client order and honouring server order are indistinguishable until you offer the same suites in different orders and compare. This page does not attempt that, and says so in the details line.

Tips & Best Practices

•Always enable server-side cipher preference to control cipher selection
•Configure cipher order from strongest (AES-256-GCM) to weakest
•Disable cipher suites you do not want entirely rather than just deprioritizing
•Test cipher ordering after any TLS configuration changes

Technical Details

Analysis: Server cipher preference detection and order verification
Ordering: Strongest-to-weakest cipher suite analysis
Preference: Server-side vs client-side cipher preference detection
Fix: Server-specific configuration for enforcing cipher preference