There is yet another "man-in-the-middle" attack that is live in the world. Unfortunately, this one is aiming at the implementation of SSL 3.0 security that goes back for 15 years.
Fortunately, most web servers are using the later TLS security protocol. However, and unfortunately, we’re still exposed to it, depending on the web server’s configuration of its security options.
The TLS protocols allow fall-back to SSL 3.0, if the security negotiation doesn’t link properly. According to Google, the fall-back mechanism is where the problem is found.
This man-in-the-middle allows the attacker to capture and use the session cookie that is established when you make a secure connection to a site using your web browser.
If you use Firefox, Mozilla has announced that SSLv3 will disabled in Firefox 34, which is due to be released on November 25th.
For users who don’t want to wait till November 25th (when SSLv3 is disabled by default in Firefox 34), we have created the SSL Version Control Firefox extension to disable SSLv3 immediately.
If you use Internet Explorer, Microsoft has just released one of their Fix-It tools to disable SSL 3.0 in Internet Explorer. Here’s the link to their Poodle Fix-It tool for IE Microsoft security advisory: Vulnerability in SSL 3.0 could allow information disclosure: October 15, 2014. The Fix-It tool will create a Restore Point before making its changes.
If you use Opera,
Opera’s solution is more complicated, because they chose to try to enable you to still use a web server that hasn’t fixed their SSLv3 problem yet.
What we have done in Opera 25 on both desktop and Android, is to add a countermeasure to the SSLv3 protocol when used. Since the attack can only be done to SSL records of certain lengths, we simply split the records into several records, where none of the records can be attacked. Adam Langley from Google who helped out developing the details of this idea named the countermeasure "anti poodle record splitting". Hopefully this will help keeping SSLv3 secure enough for a few more months, and give server owners a chance to upgrade to TLS. We have tested the splitting extensively on a big bunch of live SSLv3 servers out there and found no compatibility problems. Thus, even if any SSLv3 servers break, that will still only be a small fraction of the less than 0.5% that only supports SSLv3. We are willing to take that risk.
Next we have removed the security badge for servers that only support SSLv3 or below. This means that when you go to a SSLv3 only server, it will look as you got to a standard unencrypted http server.
Opera also supports the TLS_FALLBACK_SCSV mechanism. This is a security feature, if supported by both browser and server, that effectively stops unwanted fallbacks to lower TLS versions. Sadly, this feature is not widely supported yet, but we hope that server administrators pay attention to this attack and will upgrade their servers to support it. This way, future problems with higher TLS versions will not have the same devastating effec
If you use Chrome, Google has announced several plans for future fixes. Unfortunately, I haven’t found any solution that solves the exposure today.
In Chrome 39 (the next version), fallback to SSLv3 will be disabled by
default. SSLv3-fallback support allows a network attacker to force an
HTTPS connection to a site to use SSLv3. This version of SSL/TLS has
padding weaknesses that Google researchers recently showed can be used
to mount an attack on the confidentiality of the connection.
In Chrome 40, we plan on disabling SSLv3 completely, although we are
keeping an eye on compatibility issues that may arise. In preparation
for this, Chrome 39 will show a yellow badge over the lock icon for
SSLv3 sites. These sites need to be updated to at least TLS 1.0 before
Chrome 40 is released.
(However, a lack of a yellow badge doesn’t mean that everything will
be fine as there could still be subresources of the page that are
served over SSLv3 connections. Developers can run Chrome with
–ssl-version-min=tls1 in order to test their sites.)