POODLE and the End of SSLv3, TLS 1.0 and TLS 1.1

Key takeaways

• POODLE needed a downgrade to SSLv3 plus the ability to make the victim send many requests; with both, it recovered a byte in about 256 requests.
• TLS_FALLBACK_SCSV (RFC 7507) stopped forced downgrades; removing SSLv3 removed the problem.
• Serve TLS 1.2 and 1.3 only, with forward-secret AEAD cipher suites, and add HSTS.

In October 2014, Google researchers published "This POODLE Bites", describing a practical attack on SSL 3.0. By then SSLv3 was 18 years old and rarely chosen on purpose, but browsers would fall back to it when a connection failed, and many servers still accepted it. POODLE turned that fallback into a way to steal session cookies. It also started the process that eventually retired every protocol version older than TLS 1.2.

How did POODLE work?

It forced a downgrade to SSLv3, then used the fact that SSLv3's CBC padding is not covered by the MAC to decrypt one byte at a time.

POODLE stands for Padding Oracle On Downgraded Legacy Encryption. The attack needed two things:

1. A man-in-the-middle position to interfere with the TLS handshake, making the browser's modern attempts fail so it retried with SSLv3.
2. The ability to make the victim's browser send many requests to the target, for example with JavaScript on a page the attacker controls, while choosing the length of the path and body.

In SSLv3's CBC mode, padding bytes at the end of a record are not checked except for the last one, and the MAC does not cover them. The attacker moves a byte of the secret (a cookie, say) to the end of a block and replaces the padding block with it. The server accepts the record about once in 256 tries, and each acceptance reveals one byte. A 16-byte cookie needs only a few thousand requests.

How was it fixed?

Short term with TLS_FALLBACK_SCSV and disabling SSLv3; long term by deprecating SSLv3 entirely.

TLS_FALLBACK_SCSV is a signal value a client adds when it retries with a lower version. A server that supports something higher sees it and aborts, so an attacker cannot quietly push a connection down.

Why does this matter for identity and API servers?

Because tokens, cookies and passwords cross these connections, and a federation server or API that accepts weak protocols exposes all of them.

Bearer tokens in OAuth 2.0 rely entirely on TLS for confidentiality. A SAML response posted through the browser carries an assertion that is often valid for minutes. Session cookies on an identity provider grant single sign-on to everything. All of it depends on the transport.

What should a server offer today?

TLS 1.3 and TLS 1.2 only, with forward-secret AEAD cipher suites, a current certificate chain and HSTS.

• Protocols: TLS 1.3 and 1.2. Disable SSLv2, SSLv3, TLS 1.0 and TLS 1.1.
• TLS 1.2 cipher suites: ECDHE key exchange with AES-GCM or ChaCha20-Poly1305. Avoid CBC suites, RC4, 3DES and static RSA key exchange.
• Certificates: RSA 2048-bit or larger, or ECDSA P-256; automate renewal.
• HSTS: Strict-Transport-Security: max-age=31536000; includeSubDomains once all subdomains are ready. The Security Header Builder writes it for nginx, Apache, IIS, Jetty and static hosts.

Examples:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;

SSLProtocol -all +TLSv1.2 +TLSv1.3

Mozilla's SSL Configuration Generator is a good source of current cipher lists for each server.

What about old clients?

Find them, then upgrade or isolate them; do not keep weak protocols open for everyone.

Check server logs for the negotiated protocol version before you switch off TLS 1.0 and 1.1. Old Java runtimes, embedded devices and legacy integration tools are the usual stragglers. If one must remain, put it behind a separate endpoint with strict network restrictions, and set a retirement date. The information security guide covers transport security for identity systems in more depth, and the HSTS article shows how to add the header on Jetty-based servers.

Questions

Is TLS 1.2 still acceptable?

Yes, when configured with modern cipher suites (ECDHE key exchange with AES-GCM or ChaCha20-Poly1305). RFC 9325 recommends supporting TLS 1.3 and allows TLS 1.2. TLS 1.0 and 1.1 are deprecated.

Was POODLE only an SSLv3 problem?

The original attack was. In December 2014 a variant showed that some TLS implementations also failed to check CBC padding properly, so they were vulnerable to the same technique until patched.

Sources

• RFC 7568: Deprecating Secure Sockets Layer Version 3.0
• RFC 8996: Deprecating TLS 1.0 and TLS 1.1
• RFC 7507: TLS Fallback Signaling Cipher Suite Value (SCSV)
• RFC 9325: Recommendations for Secure Use of TLS and DTLS
• NVD: CVE-2014-3566

Tagged: SSL, TLS, Attacks, nginx, Apache HTTP Server, HSTS, Security