SECURITY ADVISORY: On version fallback vulnerability in SSL/TLS implementations (Moeller/Duong/Kotowicz POODLE attack)


In late September 2014, a new attack on SSL/TLS protocol was recognized and described by security researchers Bodo Möller, Thai Duong and Krzysztof Kotowicz [1]. The report of the attack gained high popularity in the news and raised concerns about its applicability to various network environments.


The authors’ description of the POODLE attack brings attention back to the last year’s sensational BEAST attack, essentially binding the discovered vulnerability with the latter. Yet, even though the new attack looks fairly serious and might produce really bad results for the affected parties, it would not be correct enough to collate POODLE and BEAST, as both attacks have different targets, use different methods and exploit different vulnerabilities. What we can say for sure about the relations between those two, is that POODLE can be used to prepare the environment to conduct BEAST.

The history of SSL/TLS protocol comprises of five versions: SSL 2.0 (the oldest and least secure), SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2 (the most recent and secure). TLS 1.1 and TLS 1.2 are the only versions that are considered secure today. Yet, due to the Internet’s heterogeneous nature, a certain proportion of servers running older versions of SSL/TLS are still there. Even though that proportion is negligible and primarily specific to close corporate environments, its presence plays a bad joke with those client implementations which put compatibility as their priority.

The problem here is that a lot of older servers did not implement a well-defined mechanism of reporting version incompatibility to newer clients. Many of SSL 3.0 servers went as far as silently closing the connection upon receiving a client hello message (a special TLS message sent by the client, essentially meaning an invitation to set up a secure connection) offering an unrecognized protocol version.

Due to the above specifics, a majority of newer clients implement the following SSL/TLS negotiation scheme (‘downgrade dance’). First, they try to connect with the most secure version they support (e.g. TLS 1.2). If their connection request is accepted and then immediately rejected by the server without any apparent reason, they consider the server to be one of those medieval sentinels which don’t handle TLS 1.2 correctly. They go ahead and try their chance with a lower version (TLS 1.1). In case of further failure with TLS 1.1, they keep on trying, eventually ending up with SSL 3.0 or even SSL 2.0.

What would an attacker do if he could intrude into the client-server SSL/TLS communications? He would sit on the pipe listening for the SSL/TLS client hellos. If he encounters a TLS 1.2 or TLS 1.1 hello, he would simply terminate that connection. Insecure SSL 3.0 connections will be given a green light.

As you see, this attacker’s behavior, from the client’s point of view, is fairly consistent with that of older SSL servers. As a result, after failing to connect with TLS 1.2 and TLS 1.1, the client will probably make another try with a lower protocol version… straight into embrace of the attacker, who will then use a different attack to exploit some vulnerability in that lower protocol version. Again, this might be a BEAST attack, or might as well be not.

So, POODLE itself does not actually exploit a protocol vulnerability. Instead, it exploits a common practice in SSL/TLS protocol version negotiation approach, reasoned by the need to achieve maximal compatibility with older implementations. After successful enforcement of the negotiation of an older, insecure, protocol version, BEAST, or any other attack, is conducted.

Who is affected

You are affected if your application uses the above method (trying versions in descending order one after another) for negotiating secure connections with older servers. You may also be vulnerable to BEAST if you use SSL 3.0, or if you use TLS 1.x with CBC cipher suites, and your application supports uncontrolled establishment of user-initiated HTTPS requests.

What to do

The most straightforward way to deal with POODLE is to disable anything below TLS 1.0 and do not even attempt to negotiate on SSL 2.0 and SSL 3.0 versions. For those implementations which have reasons to use SSL 3.0, a special protocol mechanism (Fallback Signaling Cipher Suite Value [2]) was introduced and is currently being integrated into SSL/TLS software around the globe.

Please also read our BEAST advisory on how to deal with BEAST.


This summary concerns POODLE approach only and does not cover the ‘associated’ BEAST attack.

Attack type: man-in-the-middle attack exploiting vulnerabilities in application protocol use practices.

Attack application point: SSL/TLS client.

Attack goal: protocol version fallback.

Attack criticality: medium.

Attack techniques: sniffer.


[1] Description of the POODLE attack: ~bodo/ssl-poodle.pdf

[2] TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks (https://

Ready to get started?

Learn more about SecureBlackbox or download a free trial.

Download Now