As you may be aware, a serious vulnerability dubbed ‘POODLE’ has been discovered in SSL version 3.0. A successful POODLE attack could allow a malicious person (with network access) to decrypt an SSLv3.0 connection.
What does that actually mean? Well, SSL is used to authenticate a server (proving they are who they say they are), and to encrypt subsequent network traffic, protecting it from eavesdropping. For instance, SSL is often used to protect communication between a browser and a webserver, or between a mail client and mail server.
SSL has been superseded by various flavours of TLS, which aren’t vulnerable and provide the same functionality. However, many applications still retain the ability to make use of SSL for compatibility reasons. A sneaky attacker (with network access) could cause sufficient disruption that a TLS capable client and server end up using SSLv3.0 instead.
So, in practice, what could an attacker pull off using the POODLE trick? They could, for example, set up a malicious wireless access point in a public place, and wait for innocent passers-by to connect their phones, laptops, etc. Once connected, the attacker could force the use of SSLv3.0 as described above, and help themselves to the encrypted traffic, pilfering online banking details, email, etc.
For a more detailed description of how the attack works, please see this excellent paper by the team who discovered it. Our blog post will focus on mitigation techniques for clients, with another to follow examining servers and infrastructure.
We Know the Drill – Time to Patch, Right?
Not exactly. The first thing to understand about POODLE; is that it exploits a fundamental flaw in the SSLv3.0 protocol. The key is not to fix antiquated SSL, but to abandon it entirely for newer and better solutions, such as TLS.
Which isn’t to say that there won’t be any patches to apply. On the contrary, vendors have already begun to release patches that disable the use of SSLv3.0; but that is precisely the point, we need to disable the use of SSLv3.0 entirely.
From a user perspective, the most effective way to protect yourself is to remove support for SSLv3.0 from your client applications. Of course, this is likely to break things while service providers get up to speed, but it’s a matter of weighing up the risks. I won’t sugarcoat the situation for you, things are fairly awkward at the moment, as different vendors take subtly different approaches to the problem. Some are disabling SSLv3.0 altogether, others plan to in the future, and some are implementing a variety of weird and wonderful mitigations.
If you’re in a hurry, and just want to know what to use; Internet Explorer with SSLv3.0 disabled, or Firefox with the SSLv3.0 extension installed are both good bets. You may also wish to avoid public WiFi hotspots, as described in the example above. For more detailed advice, please read on.
Firefox version 34 (scheduled for release on November the 5th) will drop support for SSLv3.0. In the meantime Mozilla have released an extension, which turns off SSLv3.0 and below. The extension is available here.
Google are planning to remove support for SSLv3.0 from all their products, ‘In the coming months’. Unfortunately, in the meantime there is no way to disable SSLv3.0 via the user interface. It is, however, possible to adjust the minimum TLS version when starting Chrome by adding the following flag: –ssl-version-min=tls1
The practical steps to achieve this vary depending on the operating system. In Windows, the flag may be appended to the ‘Target’ box of a Chrome shortcut. Other operating systems can launch Chrome from the command line using the flag, for instance in OS X:
open -a “Google Chrome.app” –args –ssl-version-min=tls1
Google Chrome also supports a mechanism called TLS_FALLBACK_SCSV which, when implemented by both the client and server, helps to prevent the use of SSL when TLS is available. It’s not widely supported yet, but it’s a neat idea and there’s a lot more to say on the subject; but that’s a blog post for another day.
Google’s POODLE statement can be found here.
Microsoft Internet Explorer
Disabling SSLv3.0 in Internet Explorer is fairly straightforward. Simply launch Internet Options and uncheck the SSL tick boxes in the advanced tab.
According to Microsoft’s POODLE security advisory, they are still looking into the vulnerability and have not yet decided on what action, if any, to take.
Apple have released security update 2014-005 to address the POODLE problem in OS X Mountain Lion and Mavericks, the same fix is also applied in OS X v10.10 Yosemite.
Rather than preventing the use of SSLv3.0 entirely, Apple have just disabled the parts that are vulnerable. As SSLv3.0 remains supported, pointing updated Safari at a testing site will often still produce a ‘vulnerable’ result – your mileage may vary. Apple’s own information regarding this update can be found here.
Opera are also continuing to support SSLv3.0 in Opera 25 for desktop and Android, for the time being. As with Google Chrome, Opera will support TLS_FALLBACK_SCSV. In addition, Opera are implementing a countermeasure known as ‘anti poodle record splitting’. The idea behind anti poodle record splitting, is that the attack is only successful against SSL records of certain lengths. Opera will split the lengthy chunks up, which should negate the attack.
Sites that only support SSLv3.0 or below will also lose the Opera secure ‘badge’, so the user should get some warning when visiting these websites.
The one exception to the above is Opera 12 for Linux, for which SSLv3.0 support will be disabled in the coming days. Opera’s POODLE statement can be found here.
Settings, Updates and Patches, oh my!
From a client point of view, this vulnerability is somewhat fiddly to mitigate, each application must be considered and dealt with accordingly. SSL will eventually limp off this mortal coil, hastened by ever diminishing client support, but until then it pays to be aware of the risks, and reduce them where possible.
Other Helpful Advice