Introduction

On October the 14th a paper was released on the so-called POODLE attack on SSLv3. This attack gained a lot of news presence, without introducing anything new. As a result a lot of people are asking us how to handle this. This post is to provide some insight into the real impact of the attack, and to provide guidance on the effect of and protection against the POODLE attack.

Explanation

The POODLE attack is similar to the BEAST attack, and is not a revelation of new vulnerabilities in the SSL protocol. It is a different attack using the same flaws that are already known to be present in the SSLv3 protocol. For the POODLE attack to work it requires that: * the connection that is negotiated uses SSLv3; * the attacker has the ability to manipulate data inside and outside of the encrypted connection; and * there is some kind of persistent secret inside the connection to reveal.

POODLE requires SSLv3

All versions of PolarSSL ever released support TLS 1.0 or higher as well as SSLv3. Most other SSL clients and servers out there in the world do as well. Because they support TLS 1.0 or higher they will negotiate that during the handshake by default. In a standard setup an attacker can only prevent this connection from taking place, not force it to use SSLv3.

Some browsers try to be smart and actively use some form of connection downgrade to improve interoperability with older servers and proxies. If an attacker actively manipulates the SSL handshake packets for such browsers, he can force the browser client to downgrade to SSLv3. An attacker thus requires access to and control of the network connection between the client and the server to manipulate the packets as they come along.

Perspective: If the client does not support downgrading and both sides supports TLS 1.0 or higher, you are not affected by the POODLE attack.

Perspective: If an attacker cannot gain access to your network connection, you are not affected by the POODLE attack.

POODLE requires manipulation of data

After the attacker succeeds in "downgrading" the connection to SSLv3, he then needs the ability to control the data send inside the encrypted connection.

According to the paper around 256 requests need to be sent for each byte in the secret.

This requires some form of control over the client to send over the connection. For browser-based attacks this often means the use of Javascript.

For most non-browser scenarios using SSL / TLS, this is not so easy or even impossible to do. Non-HTTP connections are not as easily manipulated as a browser is with Javascript.

Perspective: If an attacker cannot actively control sending requests and the data in them , you are not affected by the POODLE attack.

POODLE requires a persistent secret

The value of the POODLE attack lies in the fact that it can reveal a secret that is persistently present in each 'request' and can thus be revealed by the POODLE attack.

Perspective: If your protocol does not have a persistent secret that is present in the same location in each request, you are not vulnerable to the POODLE attack.

Perspective: If your secret changes every (few) requests, you are not vulnerable to the POODLE attack.

Conclusion

The POODLE attack received a lot of hype-media attention. The impact of POODLE on the existing Internet infrastructure is negligible outside of the HTTP world. The POODLE attack requires injection of something like a Javascript inside your connection and requires active manipulation of network packets.

We agree with the authors that SSLv3 is old, has flaws, and should be phased out. But this attack does not change the necessity for it. It just puts another highlight on it.

Workarounds

For workarounds in PolarSSL, please look at Security Advisory 2014-03.

We don't agree with the authors that there is no countermeasure possible this time. Browsers developers can decide to insert a random-sized header before the Cookie header to disguise the location of the session cookie. This would cripple the POODLE attack. Barking dogs don't bite.

Edit 2014-10-17: Based on feedback from reviewers, the suggested countermeasure of rotating session cookies in HTTP server frameworks has been removed.

Like this?