TLS Protocol & Cipher Scanner

Every HTTPS connection starts with a negotiation: the client offers the TLS versions and ciphers it speaks, and your server picks. That one decision fixes everything that follows — which key exchange protects the session, which ciphers encrypt it, and how much an attacker who records the traffic today can do with it tomorrow. A server is judged not by the best protocol it offers but by the worst one it still accepts, because downgrade tricks push connections toward exactly that floor.

TLS 1.3 is the version worth insisting on: handshakes complete in a single round trip (faster first bytes on every connection), the entire museum of legacy constructions — static RSA key exchange, CBC padding, RC4, SHA-1 — is simply gone, and forward secrecy stops being a configuration choice and becomes a guarantee. Forward secrecy is the quiet hero here: with ephemeral ECDHE keys, a private key stolen next year cannot decrypt the traffic an attacker recorded this year. With classic RSA key exchange, it can — retroactively, all of it.

So why do TLS 1.0 and 1.1 still show up on scans in 2026? Rarely by intent: an old load balancer that predates TLS 1.3, a hardware appliance nobody dares reboot, a distro default that shipped permissive and was never revisited. Accepting them costs real things — failed PCI DSS scans, a wider downgrade surface, and clients quietly negotiating protection that was deprecated by RFC 8996 years ago. The fix is usually one line: ssl_protocols TLSv1.2 TLSv1.3; in nginx, or SSLProtocol -all +TLSv1.2 +TLSv1.3 in Apache, then a graceful reload and a re-scan here to confirm.