In short

Lucky Thirteen (2013) leaked plaintext through timing differences in TLS CBC record processing, and POODLE (2014) exploited SSL 3.0’s loose CBC padding after forcing a fallback. Today, disable SSL 3.0, TLS 1.0 and TLS 1.1, offer only TLS 1.3 and TLS 1.2 AEAD suites so no CBC record processing remains, and never retry a failed handshake with an older protocol. TLS_FALLBACK_SCSV (RFC 7507) blocks forced fallback between supported versions.

  • Lucky Thirteen is a timing oracle: equal error messages did not mean equal work.
  • POODLE relies on SSL 3.0 padding rules, so the fix is removing SSL 3.0, not hiding errors.
  • Browsers retried failed handshakes with older protocols, which handed attackers the downgrade.
  • RFC 7568 deprecated SSL 3.0 in 2015, and RFC 8996 deprecated TLS 1.0 and 1.1 in 2021.
  • AEAD cipher suites have no separate padding and MAC steps for an attacker to time.

Incident at a glance

Dates
to
Category
Protocol attack
Organizations
  • OpenSSL Project
  • GnuTLS
  • Google Chrome
  • Mozilla Firefox
Impact
Lucky Thirteen let a network attacker recover plaintext from TLS and DTLS CBC records through MAC-check timing. POODLE recovered SSL 3.0 plaintext such as cookies at about 256 requests per byte, after forcing a browser to fall back to SSL 3.0.
How it was found
Nadhem AlFardan and Kenneth Paterson of Royal Holloway found Lucky Thirteen; Bodo Möller, Thai Duong and Krzysztof Kotowicz of Google found POODLE.

Timeline

  1. Lucky Thirteen is disclosed; GnuTLS releases fixes the same day.
  2. OpenSSL 1.0.1d, 1.0.0k and 0.9.8y address Lucky Thirteen (CVE-2013-0169).
  3. OpenSSL 1.0.1e completes the 1.0.1 fix, which was incomplete in 1.0.1d.
  4. Google discloses POODLE and recommends TLS_FALLBACK_SCSV; Mozilla announces Firefox 34 will disable SSL 3.0.
  5. OpenSSL 1.0.1j, 1.0.0o and 0.9.8zc add TLS_FALLBACK_SCSV support.
  6. RFC 7507 standardizes TLS_FALLBACK_SCSV.
  7. RFC 7568 deprecates SSL 3.0.
  8. RFC 8996 deprecates TLS 1.0 and TLS 1.1.

Verify it

  1. Run testssl.sh --poodle --tls-fallback --lucky13 host:443 and confirm no SSL 3.0, working fallback protection and no CBC suites.
  2. Offer only SSL 3.0 or TLS 1.0 from a test client and confirm the handshake fails.
  3. Break a modern handshake on purpose and confirm the client does not retry with an older version.
  4. Confirm the negotiated suite on a fresh connection is an AEAD suite.
Applies to

Legacy TLS/SSL oracle mechanisms. Lucky Thirteen and POODLE have different prerequisites and mitigations.

Part of
Collection: case studies

Fix it in your stack

Tested fixes: the vulnerable code, the fix, a plausible fix that still fails, and the regression tests that tell them apart.

Learning goals and prerequisitesAbout 18 minutes: 4 to read and 14 for the exercise

What you will learn

  • Distinguish timing and padding-format oracles.
  • Explain the relationship between fallback and protocol weakness.
  • Use evidence that matches the claimed fix.

Before you start

Engineers who configure TLS and client fallback behavior, and reviewers who assess timing and downgrade findings.

  • Distinguish CBC padding validation, MAC verification, timing leakage, and protocol fallback.

Refresh first: Padding oracle attacks

Go to the guided practice

A shared construction, two different leaks

Legacy TLS CBC records placed a MAC inside the encrypted record and added padding to reach the block size. A receiver therefore had to process decryption, padding, and MAC checks while avoiding any distinguishable outcome about intermediate validity. That ordering made apparently small implementation details security relevant; the padding-oracle guide at /domains/identity-crypto/encryption/padding-oracle-attacks/ shows the byte-level mechanism.

Lucky Thirteen, disclosed in 2013 by AlFardan and Paterson, exploited timing differences in TLS/DTLS CBC processing. Some candidate padding lengths changed the amount of hash work required during MAC verification. Repeated measurements could turn small processing differences into information about plaintext. Returning the same error alert did not necessarily equalize the amount of work.

POODLE, disclosed in 2014, exploited SSL 3.0 CBC padding rules and the ability to obtain useful valid-or-invalid behavior after replacing a ciphertext block. SSL 3.0 did not require the interior padding bytes to have the stricter TLS padding pattern. Forcing a browser to retry with SSL 3.0 was a practical route into the vulnerable protocol, but the padding weakness remains relevant whenever SSL 3.0 is used.

Name the observation channel before naming the fix

Lucky Thirteen required suitable records and many observations against vulnerable processing, with noise and protocol details affecting feasibility. A noisy network trace that shows no obvious difference does not prove the implementation safe. The timing distribution, not an explicit padding-error string, is the evidence under investigation.

POODLE’s classic browser setting combined attacker-induced requests, control of alignment, observation or modification of traffic, and SSL 3.0 CBC acceptance. An authenticating endpoint could retain the original MAC while a substituted final block occasionally decoded as acceptable padding. The details differ from simply guessing every PKCS#7 byte through a web error endpoint.

Later implementation flaws sometimes called TLS POODLE involved TLS stacks checking padding incorrectly. That does not make TLS padding rules identical to SSL 3.0. Record the exact implementation, protocol version, and flaw rather than assuming every reference to POODLE identifies the same protocol condition.

Match remediation to the causal path

Disabling SSL 3.0 removes the original POODLE protocol path. The TLS_FALLBACK_SCSV signal (RFC 7507) lets a server refuse a client’s retry at a lower version when both support a higher one, which blocks forced downgrades between supported versions. It cannot make a connection that legitimately uses SSL 3.0 secure. Removing a downgrade opportunity and removing an insecure protocol are different controls.

For Lucky Thirteen, maintained library updates and carefully reviewed constant-time handling addressed legacy CBC implementations; modern AEAD profiles avoid this padding/MAC composition. Writing a sleep into the error handler is unreliable because execution paths, scheduling, and attack sample counts vary. Hiding alert text is similarly incomplete.

Retiring a protocol can disconnect old clients; quantify that dependency and migrate it deliberately. A fallback retained for an unmeasured client population can silently become the weakest supported path. Treat the actual negotiated version and record construction as deployment evidence, not just the strongest version a service advertises.

What should you do today?

  • Disable SSL 3.0, TLS 1.0 and TLS 1.1 on every server, proxy and client library.
  • Offer only TLS 1.3 and TLS 1.2 AEAD suites, so no CBC padding or MAC-then-encrypt processing remains; the TLS guide at /domains/identity-crypto/key-management-pki/tls-pki-operations/ gives the profile.
  • Remove client code that retries a failed handshake with an older protocol version.
  • Check with testssl.sh --poodle --tls-fallback --lucky13 host:443.

An equal response is not an equal computation

For modern operation, verify a supported handshake succeeds, SSL 3.0 negotiation fails, and forced retries do not re-enable it. Check the approved TLS cipher profile separately. For a legacy timing review, combine implementation provenance and focused measurement; a small synthetic trace can teach the issue but cannot establish remote exploitability.

The exercise supplies timings and record outcomes to distinguish kinds of evidence. Its timestamps are illustrative rather than measurements of Lucky Thirteen. Their role is to expose an invalid inference: identical HTTP or TLS error labels alone say nothing about how much secret-dependent work occurred.

Guided practice

Two candidate fixes are reviewed against simplified observations.

Supplied scenario material
Plain text
Service L: every invalid record returns alert=bad_record_mac.
Class A processing times: 100,101,99,100 microseconds.
Class B processing times: 104,103,105,104 microseconds.
Service P: SSL 3.0+CBC accepted; TLS 1.2+AEAD accepted.
Fix 1: rename all alerts to error. Fix 2: disable SSL 3.0; use maintained AEAD-capable stack.

  1. 1. Compute and interpret

    Calculate mean times for classes A and B and assess the same-alert claim.

    Expected result and reasoning

    A averages 100 µs; B averages 104 µs. The supplied trace contains a timing difference despite equal alerts. Four samples do not establish a real-world statistical attack.

  2. 2. Map each fix

    State what disabling SSL 3.0 addresses and what renaming alerts leaves unresolved.

    Expected result and reasoning

    Disabling SSL 3.0 closes the original POODLE protocol path. Renaming alerts does not remove timing-dependent work. AEAD migration avoids legacy CBC padding processing for negotiated AEAD records.

  3. 3. Define boundary tests

    Write outcomes for a normal supported client, SSL 3.0-only client, and forced fallback.

    Expected result and reasoning

    The supported AEAD connection succeeds; SSL 3.0-only negotiation fails; failed modern negotiation must not trigger an SSL 3.0 retry path.

Your deliverable: A two-row causal comparison and the mean-time calculation.

The observations are supplied models. No timing experiment, SSL 3.0 attack, or TLS-library verification is performed.

Save a draft on this device to resume later. Automatic saving begins after you choose Save. Drafts are never sent by this application; use synthetic data.

No draft saved on this device yet.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

  1. AlFardan and Paterson: Lucky Thirteen disclosure. 4 February 2013.
  2. Möller, Duong and Kotowicz: This POODLE Bites. September 2014.
  3. RFC 9325: Modern TLS recommendations. November 2022 (BCP 195); updated by RFC 9852 and RFC 10015.
  4. RFC 7507: TLS Fallback Signaling Cipher Suite Value (SCSV). April 2015; obsoleted by RFC 8996.
  5. RFC 8996: Deprecating TLS 1.0 and TLS 1.1. March 2021 (BCP 195).
  6. Google Online Security Blog: This POODLE bites, exploiting the SSL 3.0 fallback. 14 October 2014.
  7. Mozilla Security Blog: The POODLE attack and the end of SSL 3.0. 14 October 2014.
  8. OpenSSL Security Advisory: SSL 3.0 fallback protection (TLS_FALLBACK_SCSV). 15 October 2014.
  9. RFC 7568: Deprecating Secure Sockets Layer Version 3.0. June 2015.

Reference information

ASVS 5.0.0 requirements
v5.0.0-12.1.1 · v5.0.0-12.1.2 · v5.0.0-11.2.5

Download this guide as Markdown