--- key: "icdp-case-lucky13-poodle" title: "Lucky Thirteen and POODLE: two different oracles" url: "https://softwaresecurity.com/domains/identity-crypto/encryption/lucky13-poodle/" api: "https://softwaresecurity.com/api/v1/articles/icdp-case-lucky13-poodle.json" domain: "identity-crypto" topic: "Identity \u0026 cryptography" type: "Case study" identifiers: ["CWE-757","CWE-208","CWE-327","A04:2025","V12.1.1","V12.1.2","V11.2.5"] tags: ["Encryption","TLS","Historical cryptographic attacks"] stages: ["design","build"] roles: ["developer"] license: "CC-BY-4.0" license_url: "https://creativecommons.org/licenses/by/4.0/" code_license: "MIT" --- # Lucky Thirteen and POODLE: two different oracles Compare two CBC oracles by their signal, protocol rules, and attacker prerequisites instead of treating them as interchangeable padding bugs. Canonical URL: https://softwaresecurity.com/domains/identity-crypto/encryption/lucky13-poodle/ ## 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 - Date: 2013-02-04 to 2014-10-14 - Category: Protocol attack - Organizations: OpenSSL Project; GnuTLS; Google Chrome; Mozilla Firefox - CVE: [CVE-2013-0169](https://nvd.nist.gov/vuln/detail/cve-2013-0169), [CVE-2013-1619](https://nvd.nist.gov/vuln/detail/cve-2013-1619), [CVE-2014-3566](https://nvd.nist.gov/vuln/detail/cve-2014-3566) - 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. 2013-02-04: Lucky Thirteen is disclosed; GnuTLS releases fixes the same day. 2. 2013-02-05: OpenSSL 1.0.1d, 1.0.0k and 0.9.8y address Lucky Thirteen (CVE-2013-0169). 3. 2013-02-11: OpenSSL 1.0.1e completes the 1.0.1 fix, which was incomplete in 1.0.1d. 4. 2014-10-14: Google discloses POODLE and recommends `TLS_FALLBACK_SCSV`; Mozilla announces Firefox 34 will disable SSL 3.0. 5. 2014-10-15: OpenSSL 1.0.1j, 1.0.0o and 0.9.8zc add `TLS_FALLBACK_SCSV` support. 6. 2015-04: RFC 7507 standardizes `TLS_FALLBACK_SCSV`. 7. 2015-06: RFC 7568 deprecates SSL 3.0. 8. 2021-03: 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. ## 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. Audience: Engineers who configure TLS and client fallback behavior, and reviewers who assess timing and downgrade findings. Before you start: - Distinguish CBC padding validation, MAC verification, timing leakage, and protocol fallback. Time: About 18 minutes: 4 to read and 14 for the exercise ## 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 material ```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. Compute and interpret Calculate mean times for classes A and B and assess the same-alert claim. Worked answer: 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. Map each fix State what disabling SSL 3.0 addresses and what renaming alerts leaves unresolved. Worked answer: 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. Define boundary tests Write outcomes for a normal supported client, SSL 3.0-only client, and forced fallback. Worked answer: The supported AEAD connection succeeds; SSL 3.0-only negotiation fails; failed modern negotiation must not trigger an SSL 3.0 retry path. Deliverable: A two-row causal comparison and the mean-time calculation. Scope: The observations are supplied models. No timing experiment, SSL 3.0 attack, or TLS-library verification is performed. Articles and teaching material: CC BY 4.0. Original executable code: MIT. Attribution: Software Security. ## Sources - [AlFardan and Paterson: Lucky Thirteen disclosure](https://www.isg.rhul.ac.uk/tls/Lucky13.html). 4 February 2013. - [Möller, Duong and Kotowicz: This POODLE Bites](https://openssl-library.org/files/ssl-poodle.pdf). September 2014. - [RFC 9325: Modern TLS recommendations](https://www.rfc-editor.org/rfc/rfc9325.html). November 2022 (BCP 195); updated by RFC 9852 and RFC 10015. - [RFC 7507: TLS Fallback Signaling Cipher Suite Value (SCSV)](https://www.rfc-editor.org/rfc/rfc7507.html). April 2015; obsoleted by RFC 8996. - [RFC 8996: Deprecating TLS 1.0 and TLS 1.1](https://www.rfc-editor.org/rfc/rfc8996.html). March 2021 (BCP 195). - [Google Online Security Blog: This POODLE bites, exploiting the SSL 3.0 fallback](https://security.googleblog.com/2014/10/this-poodle-bites-exploiting-ssl-30.html). 14 October 2014. - [Mozilla Security Blog: The POODLE attack and the end of SSL 3.0](https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/). 14 October 2014. - [OpenSSL Security Advisory: SSL 3.0 fallback protection (TLS_FALLBACK_SCSV)](https://openssl-library.org/news/secadv/20141015.txt). 15 October 2014. - [RFC 7568: Deprecating Secure Sockets Layer Version 3.0](https://www.rfc-editor.org/rfc/rfc7568.html). June 2015.