Attack of the POODLEs

Three weeks ago a group of researchers from Google announced an attack against the SSL v3 protocol (the ancestor of the TLS 1.x protocol) called POODLE (a stylish abbreviation of “Padding Oracle On Downgraded Legacy Encryption”). This attack is similar to the BEAST attack that was revealed a few years ago, and one of the researchers that found the POODLE attack was part of the team that found BEAST.

POODLE is able to quickly discover the content of a HTTPS request, such as a session cookie, but only if the connection is using the SSL v3 protocol, a version of SSL/TLS that became obsolete with the introduction of TLS 1.0 in 1999. As almost all (>99%) secure web servers now support at least TLS 1.0 (which is not vulnerable to the attack, provided the server is correctly implemented), it might sound like this attack is not very useful. Unfortunately, that is not so.

Because there are a lot of badly implemented SSL and TLS servers, if a modern browser tries to connect to a server and the server breaks the connection because it doesn’t “like” how modern the client is, the browser will try again using an older version of the SSL/TLS protocol which the server might like better. If “necessary”, the browser will (currently) go all the way back to SSL v3. This process is called version rollback, and is considered a security vulnerability (but one that is intentionally built into the browser). This means that, if the client can be tricked, for example by an attacker preventing the clients attempts to use TLS 1.0 or higher from reaching the server, into negotiating SSL v3 instead, then the client’s connection can be attacked using the POODLE attack.

Version rollback attacks against browsers have concerned me for several years, precisely because an attack against one of the older protocol versions of SSL/TLS could be discovered, leaving all clients vulnerable to such an attack. Three weeks ago this expected attack arrived.

At present there is really only one good method available to stop the POODLE attack in its tracks: Remove support for SSL v3 (you can disable this protocol in most browsers), and that is under way already:

• Opera 12’s support for SSL v3 is already being turned off remotely by Opera in all installations.
• Firefox have announced the intention to disable support for SSL v3 before December.
• Google is considering disabling SSL v3 for Chrome (this will also include versions of Opera based on the updated code base)
• Microsoft will be disabling support for SSL v3 in IE and services soon

It has been suggested that servers should also disable support for SSL v3, although there has been concern expressed that this might cause trouble for, at least, users still using IE6, for example on Windows XP.

This concern has not stopped Cloudflare from disabling SSL v3 for all sites hosted through them, including Vivaldi.net, as well as many other sites. In the two weeks since the POODLE attack was disclosed the number of servers supporting SSL v3 has been reduced from being supported by almost 100% of surveyed servers to 72.7% (a 27% reduction, most of in the first week), and approximately 20% of the remaining SSL v3-only servers also disappeared in the past three weeks (the average reduction has been about 0.005 percentage points per week since December), and the number is
now down to 0.59%, from 0.71%.

However, while disabling SSL v3 in clients and servers will remove the threat of POODLE, it will not remove the threat that something similar might be accomplished against TLS 1.0 or later, and browsers (even Opera 12) are still allowing version rollback attacks to succeed, and there are no indications that they will stop doing so, because doing so would reduce the experience for the user whenever he or she tries to connect to a site having a bad server, or if the connection is just passing through a router that doesn’t like modern TLS versions or features (Google’s Adam Langley has documented that they exist).

 

Countermeasures against version rollback attacks

So, what can be done to prevent as many version rollbacks as possible?

As a mitigating measure, after the introduction of the TLS Renegotiation Information (Renego) extension patch to TLS, I added code in the Opera versions I worked on (up to Opera 12) that used the existence of the Renego extension as a proxy indication for the server not requiring version rollback for connections. Even before Opera remotely disabled SSL v3, this made Opera 12 able to resist the POODLE attack when connecting to the 88% Renego patched of all the servers scanned by my TLS Prober. (Please note that this particular functionality does not exist in Opera versions released after version 12.)

I proposed this rollback prevention heuristic to the IETF‘s TLS Work Group, but it was not adopted.

The TLS Work Group instead chose to develop a different method, called TLS_FALLBACK_SCSV, that signals to the server that the client is connecting using an older TLS version than the newest version it supports, and then leaves it up to the server to decide (if it even recognizes the signal) whether to continue with the connection attempt, or close the connection with an error.

The main drawback of this method is that as long as the server does not support the signal, the client will be vulnerable to the version rollback attack and, consequently, the POODLE attack or another attack against an older version of SSL/TLS.

At present, even though the fallback SCSV specification has not been completed (it is undergoing final review in the Working Group), about 14% of the servers surveyed by my TLS Prober support the fallback SCSV method, as it has been implemented in NSS, and recently OpenSSL. Considering how new the feature is, I am a little surprised the coverage is so high. However, considering that it’s taken almost 5 years to reach 88% coverage of the patch for the very severe TLS Renego problem, I think that achieving that level of coverage for this new signal is going take much longer.

A potentially troublesome issue is that about 2.5% of the servers I scanned appear to be intolerant to the signal used by the proposed standard (and 4.9% are intolerant of the way Chrome 38 currently implements the fallback signal, but the Chromium team is already considering changing their implementation), and rather than just continuing as normal, as they are supposed to, these servers closes the connection when they see the signal. This will at least cause problems whenever the signal has to be used during a fallback (it is not used during normal connection attempts, only when a fallback is performed).

However, there are also a number of servers that do not tolerate modern TLS protocol versions and features, and in such cases the fallback signal has to be used when falling back, and intolerance for the signal might cause issues for users during normal surfing (and not when they are attacked). Fortunately, it looks like the number of servers with this specific combination of problems is very low, less than 0.1%, and the number of detected servers is so small that they may, in fact, be false positives, and more research is needed before it is possible to definitely say if we have a problem.

The reason for selecting this particular signaling method (camouflaging it as an encryption method number) was that it should be ignored by servers and intermediates that did not support that number. Looks like some servers did not.

Would choosing an alternative value for the signal help? Unfortunately not, at least completely. I tested 3 different values, and for each about 0.6% of the servers did not accept the value, but not the same group of servers for each value, although there was half in each group that did not accept the others.

It would be rather ironic if a method designed to detect attacks and interoperability problems has to be updated with a new method to work around interoperability problems.