SSL Cipher Suite Checker

A cipher suite is a set of algorithms that help secure a TLS/SSL connection. It specifies the key exchange algorithm (e.g., ECDHE, RSA), authentication method (e.g., RSA, ECDSA), bulk encryption cipher (e.g., AES-GCM, ChaCha20), and message authentication code (e.g., SHA256, Poly1305). During the TLS handshake, the client and server negotiate which cipher suite to use from their mutually supported sets.

TLS 1.3 (2018) offers significant improvements over TLS 1.2: faster handshake (1-RTT vs 2-RTT), removes obsolete algorithms (RSA key exchange, CBC mode ciphers, SHA-1), mandates forward secrecy for all connections, and simplifies cipher suites to only 5 core options. TLS 1.3 is strongly recommended for all modern deployments.

To achieve an A+ rating: 1) Enable only TLS 1.2 and TLS 1.3 (disable TLS 1.0/1.1). 2) Use strong cipher suites with forward secrecy (ECDHE or DHE key exchange). 3) Disable all EXPORT and LOW grade ciphers. 4) Implement HSTS with a long max-age and include subdomains. 5) Ensure your certificate chain is complete and uses SHA-256 signatures. 6) Enable Certificate Transparency.

Forward Secrecy (FS) ensures that even if a server's private key is compromised in the future, past encrypted sessions cannot be decrypted. This is achieved using ephemeral key exchange algorithms like ECDHE or DHE, where session keys are generated per-connection and discarded afterward. Without FS (using static RSA key exchange), an attacker who obtains the private key can decrypt all previously recorded traffic.

Avoid: NULL ciphers (no encryption), EXPORT-grade ciphers (intentionally weakened), RC4 (completely broken), 3DES (vulnerable to Sweet32 attack), CBC-mode ciphers with TLS 1.0 (BEAST attack), MD5-based suites, anonymous Diffie-Hellman, and static RSA key exchange (no forward secrecy). Also avoid any suite using SHA-1 for signatures in certificates.

A certificate chain links your server's certificate through intermediate CA certificates to a trusted root CA. For proper validation: 1) The full chain (server cert + intermediates) must be served. 2) Certificates must be in the correct order. 3) All certificates must be valid (not expired). 4) Use SHA-256 signatures, not SHA-1. Missing intermediates cause trust errors on some clients.

Recommendations: Quarterly routine checks, after any server configuration changes, after certificate renewal, and when new vulnerabilities are disclosed (e.g., Heartbleed, POODLE, FREAK). Automated monitoring tools can alert you to configuration drift or impending certificate expiry. The SSL Labs API used by this tool caches results, so frequent re-scans may show cached data.