Get a free application, infrastructure and malware scan report - Scan Your Website Now

Subscribe to our Newsletter
Try AppTrana WAAP (WAF)
Managed WAF Start at $99

All You Need To Know About POODLE Vulnerability

Posted DateOctober 15, 2014
Posted Time 3   min Read

Today, Google announced a vulnerability in the implementation of the SSL 3.0 protocol potentially compromising secure connections online. POODLE (Padding Oracle on Downgraded Legacy Encryption) is a new security hole in Secure Socket Layer (SSL) 3.0 that makes the 15-year-old protocol nearly impossible to use safely. The “Poodle” is a protocol flaw, not an implementation issue; every implementation of SSL 3.0 suffers from it. The TLS versions are not affected (neither is DTLS).

The Poodle attack works in a chosen plaintext context. The attacker is interested in data that gets protected with SSL, and he can:

1)      Inject data of his own before and after the secret value that he wants to obtain;

2)      Inspect, intercept and modify the resulting bytes on the wire.

The main and about only plausible scenario where such conditions are met is a Web context: the attacker runs a fake WiFi access point and injects some Javascript of his own as part of a Web page (HTTP, not HTTPS) that the victim browses. The evil Javascript makes the browser send requests to an HTTPS site (say, a bank Web site) for which the victim’s browser has a cookie. The attacker wants that cookie. The attack proceeds byte-by-byte. The attacker’s Javascript arranges for the request to be such that the last cookie byte occurs at the end of an encryption block (one of the 8-byte blocks of 3DES) and such that the total request length implies full-block padding.

Can you detect Poodle attacks on your network?

You don’t! Since the most probable attack setup involves the attacker luring the victim on his network, not yours.

Although, on the server-side, you may want to react to an inordinate amount of requests that fail on a decryption error. Not all server software will log events for such cases, but this should be within the possibilities of any decent IDS system.

Recommendations by Google:

The attack described above requires an SSL 3.0 connection to be established, so disabling the SSL 3.0 protocol in the client or in the server (or both) will completely avoid it. If either side supports only SSL 3.0, then all hope is gone, and a serious update required to avoid insecure encryption. If SSL 3.0 is neither disabled nor the only possible protocol version, then the attack is possible if the client uses a downgrade dance for interoperability.

Disabling SSL 3.0 entirely right away may not be practical if it is needed occasionally to work with legacy systems. Also, similar protocol version downgrades are still a concern with newer protocol versions (although not nearly as severe as with SSL 3.0).

The TLS_FALLBACK_SCSV mechanism from [draft­ietf­tls­downgrade­scsv­00] addresses the broader issue across protocol versions, and we consider it crucial especially for systems that maintain SSL 3.0 compatibility.

The following recommendations summarize how TLS_FALLBACK_SCSV works:

TLS clients that use a downgrade dance to improve interoperability should include the value 0x56, 0x00 (TLS_FALLBACK_SCSV) in ClientHello.cipher_suites in any fallback handshakes. This value serves as a signal allowing updated servers to reject the connection in case of a downgrade attack. Clients should always fall back to the next lower version (if starting at TLS 1.2, try TLS 1.1 next, then TLS 1.0, then SSL 3.0) because skipping a protocol version forgoes its better security. (With TLS_FALLBACK_SCSV, skipping a version also could entirely prevent a successful handshake if it happens to be the version that should be used with the server in question.) In TLS servers, whenever an incoming connection includes 0x56, 0x00 (TLS_FALLBACK_SCSV) in ClientHello.cipher_suites, compare ClientHello.client_version to the highest protocol version supported by the server. If the server supports a version higher than the one indicated by the client, reject the connection with a fatal alert (preferably, inappropriate fallback (86) from [draft­ietf­tls­downgrade­scsv­00]).

This use of TLS_FALLBACK_SCSV will ensure that SSL 3.0 is used only when a legacy implementation is involved: attackers can no longer force a protocol downgrade. (Attacks remain possible if both parties allow SSL 3.0 but one of them is not updated to support TLS_FALLBACK_SCSV, provided that the client implements a downgrade dance down to SSL 3.0.)

web application security banner

Spread the love

Join 47000+ Security Leaders

Get weekly tips on blocking ransomware, DDoS and bot attacks and Zero-day threats.

We're committed to your privacy. indusface uses the information you provide to us to contact you about our relevant content, products, and services. You may unsubscribe from these communications at any time. For more information, check out our Privacy Policy.

Related Posts

Exploiting Command Injection Vulnerability
While the world is shell shocked, our customer are preparing for the weekend

The world is shell-shocked! And while the system owners are busy understanding the vulnerability and are still finding out ways to detect it, attackers are not showing any mercy. We.

Spread the love

Read More


Fully Managed SaaS-Based Web Application Security Solution

Get free access to Integrated Application Scanner, Web Application Firewall, DDoS & Bot Mitigation, and CDN for 14 days

Know More Take Free Trial


Indusface is the only cloud WAAP (WAF) vendor with 100% Customer Recommendation for 3 consecutive years.

A Customers’ Choice for 2022 and 2023 - Gartner® Peer Insights™

The reviews and ratings are in!