Cybersecurity glossary
What is Lucky Thirteen?
Learn what the Lucky Thirteen attack is, how TLS CBC MAC-then-pad timing leaked plaintext, which stacks were affected, and why AEAD cipher suites and constant-time fixes closed the oracle.
Definition
Lucky Thirteen is a timing side-channel attack against TLS (and DTLS) implementations using CBC cipher suites with the MAC-then-pad-then-encrypt construction: small differences in how padding and HMAC failures are processed can reveal plaintext bytes to a network attacker who carefully measures response times.
Why Lucky Thirteen mattered
TLS spent years hardening against BEAST-style chosen plaintext and against loud padding oracles that returned different alerts. Lucky Thirteen, published by Nadhem AlFardan and Kenny Paterson, showed another path: micro-timing around HMAC and padding validation in CBC cipher suites.
Even when implementations tried to hide error causes, the CPU work still depended on how padding bytes lined up with MAC checks. On real networks—especially local or low-jitter paths—those differences could be measured often enough to recover plaintext. The attack forced TLS libraries into careful constant-time redesigns and accelerated the migration to AEAD.
What Lucky Thirteen actually is
Lucky Thirteen is a remote timing attack against the TLS record layer’s CBC construction: pad the plaintext, compute a MAC, then encrypt (MAC-then-encrypt). Mangled ciphertexts take slightly different amounts of time to reject depending on guessed padding and MAC alignment. Those timings form an oracle similar in spirit to padding oracles, but driven by clocks instead of error strings.
Target construction
TLS/DTLS CBC suites using MAC-then-pad-then-encrypt record protection.
Leak type
Processing-time differences—not necessarily different alert codes.
Attacker position
Ability to inject or observe crafted TLS records and measure response latency precisely.
Recoverable data
Plaintext bytes from encrypted records, including HTTP secrets in vulnerable deployments.
How the Lucky Thirteen attack works
Establish a CBC TLS session
Ensure the connection uses a vulnerable CBC cipher suite rather than an AEAD suite.
Craft boundary-sensitive records
Modify ciphertext so decrypted padding and HMAC input lengths sit on critical block boundaries.
Measure rejection timing
Collect many samples of how long the peer takes to abort or respond after each probe.
Infer plaintext constraints
Timing clusters reveal whether padding/MAC hypotheses about secret bytes were correct.
Iterate across bytes
Repeat adaptive probes until enough plaintext is recovered for cookie theft or further abuse.
Practicality depends on network jitter and implementation. Datacenter-adjacent attackers historically had an easier time than noisy cross-continent paths—but security goals cannot assume attackers always have bad timing conditions.
Lucky Thirteen versus related CBC failures
| Property | Lucky Thirteen | POODLE | BEAST |
|---|---|---|---|
| Primary signal | MAC/padding timing | Padding validity behavior | Predictable IVs + chosen plaintext |
| TLS versions of note | CBC suites across TLS eras | SSL 3.0 (classic) | TLS 1.0 CBC |
| Needs different alerts? | No (timing suffices) | Oracle via padding checks | Ciphertext comparison |
| Best modern escape | AEAD-only suites | Disable SSL 3.0 | TLS 1.1+ / disable TLS 1.0 |
| Library patches matter? | Yes—constant-time CBC | Protocol disable primarily | Record splitting + upgrades |
Who was affected
TLS and DTLS stacks that implemented CBC record processing with data-dependent timing were in scope, including widely used libraries before patches. Sites that still preferred CBC suites—sometimes for FIPS or legacy client reasons—remained exposed longer than sites that had already standardized on GCM.
DTLS was particularly interesting in research because its UDP nature and timing characteristics could differ from TCP TLS, but the core lesson applied across both.
Mitigations
Prefer AEAD cipher suites
AES-GCM and ChaCha20-Poly1305 remove the MAC-then-encrypt CBC record path entirely.
Patch TLS libraries
Apply constant-time CBC verification fixes for any stack that must keep CBC temporarily.
Consider encrypt-then-MAC
RFC 7366 changed ordering for CBC to reduce this class of issues where supported.
Move to TLS 1.3
TLS 1.3 mandates AEAD record protection, eliminating classic Lucky Thirteen CBC suites.
What practitioners should do today
- Disable CBC cipher suites on public terminators whenever client compatibility allows.
- Prefer TLS 1.2 AEAD and TLS 1.3; monitor for unexpected CBC negotiations.
- Keep OpenSSL, BoringSSL, Schannel, JSSE, and appliance firmware patched for historical timing fixes.
- Replace embedded devices that only speak legacy CBC TLS.
- Treat precise remote timing as in-scope for threat models on low-latency networks.
- Avoid ‘CBC required for FIPS’ myths without checking current approved AEAD options.
- Validate DTLS configurations separately if you terminate DTLS for VPN or IoT.
- Document any remaining CBC exceptions with owners and removal deadlines.
Lessons Lucky Thirteen left for implementers
Lucky Thirteen proved that secret-dependent CPU work is an API. Attackers will measure it. It also proved that protocol designs which decrypt and verify in delicate orders create long-term maintenance debt across every library.
The strategic fix was not endless micro-optimization alone—it was changing defaults to AEAD so the dangerous composition exits the ecosystem.
The practical takeaway
Lucky Thirteen turns TLS CBC MAC-and-padding timing into a decryption oracle. Patched libraries and AEAD-only configurations close it. If any edge still offers unpatched CBC TLS “for one old client,” you are keeping a timing oracle on the menu—remove it or isolate it aggressively.
Related security terms
Padding Oracle Attack
Broader oracle class; Lucky Thirteen realizes a timing-based padding/MAC oracle in TLS CBC.
POODLE (CVE-2014-3566)
Related CBC padding weakness narrative that also pushed ecosystems off fragile CBC paths.
Authenticated Encryption with Associated Data (AEAD)
Cipher modes that replace MAC-then-encrypt CBC suites Lucky Thirteen targeted.
HMAC
The MAC whose verification timing interacted with padding checks in vulnerable stacks.
Side-Channel Attack
Category of leaks via timing rather than explicit error strings.
Frequently asked questions
What is Lucky Thirteen in simple terms?
It is a way to decrypt parts of old-style TLS CBC traffic by measuring how long the server takes to reject bad records. Tiny timing differences act like a yes/no oracle about secret bytes.
Why the name ‘Thirteen’?
The attack analysis centers on TLS header sizes and HMAC block boundaries—thirteen bytes of TLS header material figure prominently in the timing distinctions researchers exploited.
Does Lucky Thirteen need distinct TLS alert messages?
No. Classic Lucky Thirteen focuses on timing even when alerts look the same, which made it harder to dismiss as a mere error-string bug.
Which cipher suites were affected?
TLS CBC suites that used MAC-then-encrypt (for example many AES-CBC and 3DES-CBC configurations of that era), including DTLS variants in some stacks.
Is AES-GCM vulnerable to Lucky Thirteen?
No. AEAD suites such as AES-GCM and ChaCha20-Poly1305 do not use the TLS CBC MAC-then-pad construction Lucky Thirteen targets.
How was it mitigated?
Libraries shipped constant-time CBC processing patches, and operators moved to AEAD cipher suites—removing the vulnerable construction entirely.
Is Lucky Thirteen still practical on the open Internet?
Against fully patched modern stacks using only AEAD, no. Residual risk remains on unpatched embedded TLS, outdated appliances, or forced CBC-only configurations.
References
Explore authoritative guidance and frameworks related to lucky thirteen.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.