Bug Circuit

Free tool · no signup

TLS cipher suite checker

Paste the cipher suites your server offers and see which are safe, which are legacy, and which should be switched off, with the reason for each in plain words.

By the Bug Circuit security team · Last updated

Paste your cipher suites

Paste a list to check it.
A good TLS 1.2 list (Mozilla intermediate), for Nginx
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;
Which cipher suites are safe? TLS 1.3 suites, and TLS 1.2 suites that use ECDHE or DHE key exchange with AES-GCM or ChaCha20-Poly1305. Anything with RC4, 3DES, export or null settings, or without forward secrecy, should be disabled. Paste your list to see where each one stands.

How it works

What a cipher suite name says

A TLS 1.2 suite name packs four choices into one string. In TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 the first part is the key exchange (ECDHE), then the authentication used for the certificate (RSA), then the bulk cipher and mode (AES 128 in GCM mode) and finally the hash (SHA-256). OpenSSL writes the same suite as ECDHE-RSA-AES128-GCM-SHA256, and this tool reads both. TLS 1.3 simplified this: its five suites name only the cipher and the hash, and the key exchange is always ephemeral.

Two properties matter most. Forward secrecy means each connection uses a fresh key, so a stolen server key cannot decrypt traffic that was recorded earlier. It comes from ECDHE or DHE key exchange. Authenticated encryption (AEAD, such as GCM or ChaCha20-Poly1305) protects against the padding and timing attacks that hit the older CBC mode.

How the tool sorts them

Recommended: TLS 1.3 suites, and TLS 1.2 suites with forward secrecy and an AEAD cipher. This follows RFC 9325, the current best-practice document for TLS. Legacy: forward secrecy but CBC mode, which still works but is the source of attacks such as BEAST and Lucky13. Weak: no forward secrecy, typically static RSA key exchange such as AES128-SHA, which TLS 1.3 removed. Insecure: RC4 (banned in 2015), single DES, 3DES (open to the Sweet32 attack), export-grade suites (FREAK and Logjam), anonymous suites with no authentication, null encryption and anything using MD5.

The classification is by the suite itself. Whether you are at risk also depends on the protocol versions you allow and on the server key and groups, so turn off TLS 1.0 and 1.1 as well, and use at least a 2048-bit DHE group if you offer DHE.

Getting your list and fixing it

To see what your server offers, run nmap --script ssl-enum-ciphers -p 443 yourdomain.com, or use an online scanner, and paste the suite names. To see what a server is configured with, look at ssl_ciphers in Nginx or SSLCipherSuite in Apache. The tool prints your list without the weak and insecure suites, and a reference list from Mozilla's Server Side TLS guidance that works for nearly every site today.

Worked examples

A modern suite

ECDHE-RSA-AES128-GCM-SHA256

Recommended. Forward secrecy and authenticated encryption.

ECDHE gives forward secrecy and GCM is an authenticated mode, so this passes both tests.

A suite that should go

DES-CBC3-SHA

Insecure. 3DES has a 64-bit block size and is open to the Sweet32 attack.

It also has no forward secrecy, because it uses static RSA key exchange. Browsers and NIST have retired it.

Works, but legacy

ECDHE-RSA-AES256-SHA384

Legacy. Forward secrecy, but CBC mode.

Keep it only if you must support old clients, and list the GCM suites first.

Frequently asked questions

What is forward secrecy?
Each connection uses a fresh key that is thrown away afterwards, so an attacker who steals your server key later cannot decrypt traffic they recorded earlier. ECDHE and DHE key exchange provide it.
Should I disable TLS 1.0 and 1.1?
Yes. Both were deprecated in 2021 (RFC 8996) and browsers have removed them. Allow TLS 1.2 and TLS 1.3.
Is AES-CBC insecure?
Not broken outright, and it is fine when implemented well, but it has produced a string of attacks such as BEAST and Lucky13. Prefer AES-GCM and ChaCha20-Poly1305, and keep CBC only for clients that need it.
Why is static RSA key exchange marked weak?
It has no forward secrecy. Anyone who obtains the server's private key later can decrypt every recorded connection. TLS 1.3 removed it for that reason.
How do I see which suites my server offers?
Run nmap --script ssl-enum-ciphers -p 443 yourdomain.com, or openssl s_client with a specific -cipher to test one, or use an online TLS scanner.
What list should I use in Nginx?
The Mozilla intermediate list shown on this page, with ssl_protocols TLSv1.2 TLSv1.3. It supports every browser from the last several years.
Does a good cipher list make my site secure?
It secures the connection. It does nothing about the application behind it, so a vulnerable plugin or weak login stays vulnerable.

Keep reading

SSL Certificate CheckerExpiry, chain and protocol problems.SSL Certificate and CSR DecoderRead a certificate in your browser.Security Headers GeneratorHSTS and more for your web server.CAA Record GeneratorChoose who may issue your certificates.

See what attackers see, for free

Run the free passive check on your website. No login, no impact on your site, results in seconds.

Ready for the full manual audit? See pricing

TLS Cipher Suite Checker and Explainer · Bug Circuit