Our TLS Cipher Scanner probes a server to identify all supported cipher suites across different TLS versions. It categorizes ciphers by strength and security level, helping you identify weak or deprecated ciphers like RC4, 3DES, and CBC-mode ciphers. Use it to harden your server's cipher configuration and ensure only modern, secure ciphers are available.
How to Use
1Enter the server domain or hostname to scan.
2Click "Check" to start the cipher scan.
3Review the list of supported ciphers per TLS version.
4Identify and disable any weak or deprecated ciphers.
Use Cases
•Audit server cipher configuration for security compliance
•Detect weak ciphers like RC4, 3DES, or export-grade ciphers
•Verify only TLS 1.2/1.3 modern ciphers are enabled
•Prepare for security audits and penetration testing
Frequently Asked Questions
RC4 is broken outright and should be treated as unusable. 3DES has a birthday-bound collision problem that gives it an effective strength well below its nominal 112 bits, which is why it was phased out. Export-grade ciphers were deliberately weakened for export control reasons. CBC-mode suites remain a judgement call: they are not fundamentally broken, but they have a long history of padding-oracle problems such as POODLE, so preferring GCM or ChaCha20 removes the whole category of risk at no cost.
On TLS 1.3 you have almost no choice, and that is the point: the protocol specifies only AEAD suites, so every client that speaks 1.3 already has safe options. Under TLS 1.2, prefer ECDHE suites with AES-GCM or ChaCha20-Poly1305, which gives forward secrecy and authenticated encryption together. A concise TLS 1.2 list is ECDHE-ECDSA-AES128-GCM-SHA256 together with ECDHE-RSA-AES128-GCM-SHA256 and their ChaCha20 equivalents, dropping everything else.
Yes, and that is the point of scanning per version rather than once. The same server can offer an excellent set of suites on TLS 1.3 and still negotiate a broken one on TLS 1.0, and clients pick a protocol before they pick a cipher. Reporting what each version negotiates separately shows which configuration a legacy client would actually end up with, rather than a single result that flatters the server's best case and hides its worst one.
Tens of seconds, and the reason is the number of connections rather than any processing here. A full scan completes a separate handshake for every protocol version and every cipher suite you offer, and each handshake is a round trip to your server across the internet. A server that rate-limits, sits behind a slow path, or has a deliberately long handshake queue makes it considerably longer. That cost is why periodic full scans work better as a scheduled job than as something run on every page load.
Because one connection only proves one suite works. A server may offer an excellent suite and also accept a broken one, and the broken one is what a downgrade-capable attacker would aim for. Per-suite probing reveals the whole accepted set, so a weak suite remaining negotiable is visible even though your own browser never chose it.
That it is configured correctly. Refusing suites like RC4, 3DES or static RSA is the expected behaviour, not a limitation. Scan results where the weak suites are rejected and only modern ones accepted represent a well-configured server, and treating a refusal as a problem inverts the meaning of the test.
Almost certainly a load balancer or CDN in between. Whichever component terminates TLS is what answers the probe, and it may be configured differently from your origin, or may terminate for some source addresses and pass through for others. Scanning from a second vantage point distinguishes a genuine origin problem from one introduced on the path.
It means the suites this scan offers were handled correctly on the connection tested. It cannot see cipher lists you did not offer, behaviour specific to other client types, or settings on a proxy ahead of the origin. Treat a clean scan as evidence about that path, and read the configuration review pages alongside it for the fuller picture.
Enough to include the legacy families that matter alongside the modern ones. Missing static RSA or CBC suites means a scan cannot detect that they are still negotiable, which is the most important thing to check. The set on this page covers the mainstream modern suites plus those legacy families specifically for that reason.
What Is Scanned
A scanner offers suites one at a time and records which the server will complete a handshake with, which is a far stronger signal than one negotiation.
1Offer a representative set of suites individually, each in its own connection. A single handshake only tells you one suite works; per-suite probing tells you the whole set the server will accept.
2Record which were accepted and which were refused, since refusal is the outcome you want for the weak ones and acceptance is the finding. A server that will not negotiate RC4 is behaving correctly.
3Flag legacy acceptance specifically, — suites without forward secrecy or using CBC — because those are the ones an attacker would aim a downgrade at, even when your own connections pick something better.
What a scan cannot see matters here: suites offered only to other client types, and anything on a proxy ahead of the origin. Where a load balancer terminates TLS, that is the layer being scanned rather than your application server.
Tips & Best Practices
•Run cipher scans after every TLS configuration change
•Compare cipher scans before and after hardening to verify improvements
•Use cipher scan results to create standardized configurations
Technical Details
Ciphers: 300+ cipher suites including all standard configurations Testing: Direct connection testing for accurate cipher detection Rating: A-F rating for cipher configuration security Output: Complete cipher list with security assessment
