SSL Toolkit Logo
Tools Features Compare FAQ Login

Lucky 13 Checker

Check for Lucky 13 timing attack vulnerability

About Lucky 13 Checker

Our free Lucky 13 Checker tests your TLS server for vulnerability to the Lucky 13 timing attack (CVE-2013-0169). This attack exploits timing differences in CBC mode padding verification during decryption, potentially allowing attackers to recover plaintext from encrypted connections.

How to Use

  1. Enter the domain name of the server you want to test
  2. Click "Run" to perform the Lucky 13 vulnerability check
  3. Review the results to determine if your server is affected

Use Cases

  • •Security auditing of TLS implementations for timing vulnerabilities
  • •Compliance verification for PCI DSS and other security standards
  • •Pre-deployment vulnerability assessment of new server configurations

Frequently Asked Questions

Lucky 13 (CVE-2013-0169) is a timing side-channel attack against CBC-mode cipher suites in TLS. It exploits the fact that MAC padding verification takes measurably different amounts of time depending on the padding length, allowing an attacker to decrypt intercepted traffic.
The best protection is to disable CBC-mode cipher suites and use only AEAD ciphers like AES-GCM or ChaCha20-Poly1305. Most modern TLS libraries have implemented mitigations, but disabling CBC ciphers entirely eliminates the risk.
While the attack was disclosed in 2013, many legacy servers still run older TLS implementations with CBC ciphers enabled. The vulnerability persists on systems that have not been patched or updated to use modern cipher suites.
A timing attack that recovers plaintext from CBC-mode ciphersuites in TLS by measuring tiny differences in how servers handle padding errors. It needs many connections and a man-in-the-middle position, so it is not a drive-by risk — but it is a real one against 1.2-and-below CBC traffic, and the principled fix is to stop negotiating the vulnerable combination rather than to patch around the timing.
Because cipher-suite names do not say CBC when they are CBC. Suites like ECDHE-RSA-AES128-SHA are CBC-mode but contain no such substring, so searching names for CBC misses nearly all of them — an earlier version of this check did exactly that. AEAD suites always advertise themselves as GCM, ChaCha20-Poly1305 or CCM, so ruling those out identifies CBC reliably.
Not necessarily. The finding describes the suite negotiated with this probe, proving the server will still select CBC for some clients. Attackers position themselves as exactly such a client. Either prefer AEAD suites server-side so CBC is never chosen while modern clients exist, or disable the CBC suites outright if your client base allows it.
For connections that actually use 1.3, yes: the protocol removed CBC cipher suites entirely, so there is nothing to attack. The residual risk is version negotiation — a server supporting both 1.3 and 1.2 with CBC suites can still be talked down to the vulnerable combination. The durable fix pairs 1.3 support with disabling the old versions, confirmed by the downgrade page.
Moderate: not a drop-everything incident, but not a wont-fix either. Exploitation needs traffic interception plus millions of crafted connections, which narrows the threat to targeted attacks on high-value sessions. Still, the remediation — preferring AEAD, then disabling CBC suites — is a routine configuration change with no compatibility cost for modern clients, so there is little reason to carry the finding.

How the Check Works

Lucky 13 is a timing attack against CBC-mode ciphers in TLS 1.2 and below. This page performs a live handshake, reads the negotiated protocol and cipher, and judges vulnerability from those two measured facts — it never sends attack traffic.

  1. 1Handshake and record the suite. The probe notes the protocol version and the cipher the server selected for this connection, which is the suite a real client in this position would use.
  2. 2Exclude everything AEAD first. GCM, ChaCha20-Poly1305 and CCM suites are not CBC by construction and are cleared immediately — as are stream and null suites, which have their own problems but not this one. OpenSSL names CBC suites without the letters CBC, so exclusion is the only reliable classification.
  3. 3Combine with the version. A CBC suite under TLS 1.0, 1.1 or 1.2 is reported as potentially vulnerable; the same suite family under TLS 1.3 cannot occur, since 1.3 removed CBC entirely — which is why a 1.3-only server is categorically clear.

The verdict is about the negotiated suite, not the server's whole configuration: a server offering both CBC and AEAD suites may still negotiate CBC with some clients. For the full offering picture, pair this with the cipher-scanner pages.

Tips & Best Practices

  • •Apply Lucky13 mitigation patches to prevent timing attacks
  • •Use constant-time implementations for TLS operations
  • •Monitor for Lucky13 vulnerability in your TLS stack
  • •Test Lucky13 mitigation effectiveness after patching

Technical Details

Vulnerability: Lucky13 timing attack on CBC ciphers
Mitigation: Constant-time padding validation
Affected: TLS implementations using CBC cipher suites
Output: Lucky13 vulnerability assessment and mitigation

Related Tools

SSL Certificate Checker Protocol Downgrade Detector MITM Detector Nginx Config Validator SSL/TLS Protocol Analyzer PCI DSS Compliance Checker