SSLv3 is so old that the connections it is supposed to protect can be decrypted. Google researchers have discovered that an attacker can force the use of a weak protocol.

The SSLv3 protocol is many years old and is still supported as a fallback by almost all servers and browsers. Google researchers recently introduced a new attack called Poodle (PDF) that takes advantage of this fallback: Almost all encrypted connections on the network can be broken using Poodle.

An attacker could force the use of the legacy SSLv3 protocol. This requires intervention in establishing the SSL/TLS connection. If the client and server agreed to connect using SSLv3, the encryption could be attacked and sensitive data could be decrypted.

Attackers could, for example, steal session cookies and freely use the user account. The name of the vulnerability, Poodle, comes from the similarity to the BEAST attack (PDF) that occurred several years ago: insufficiently secure padding in CBC mode led to the acronym Poodle (“Padding Oracle On Downgraded Legacy Encryption”).

The attacker is in the “man in the middle” position, that is, exactly where all network packets pass. The Secret Service may be in the same position as anyone else who is logged into the same WLAN as you. Poodle needs to transition back to SSLv3, and this is not particularly difficult since almost all servers and clients still support this transition.

The attack can only be prevented if at least the client or server does not agree to a rollback. It also requires that the attacker be able to execute script code on the victim's device. For the man in the middle, this is also easy: the code can be installed on unencrypted websites that the user is currently visiting. Most browsers also execute embedded code.

To understand the real problem, it is necessary to clearly understand the objectives of Secure Socket Layer: in addition to encrypting data, SSL is also responsible for ensuring integrity. This means that subsequent changes and manipulations must be prevented. This integrity is ensured by the message authentication code - MAC.

When SSL was introduced, the sequence had to be negotiated, and since then MAC-then-encrypt has been used as a standard, i.e. integrity check first, encryption second. The MAC is calculated and added to the plain text data that needs to be protected with encryption. The entire packet is then encrypted. This procedure often led to problems.

This is because encryption is often done in blocks whose length is specifically defined: think AES or 3DES. The actual length of the encrypted data rarely reaches the full block size, so padding after the MAC address is necessary to achieve the required length. This process is called filling.

The padding is encrypted but not MAC protected, so there is no integrity check (manipulation check). SSLv3 now allows the attacker to choose the padding almost freely, only the last byte must correctly name the padding length. If the length specification is incorrect, the MAC is output in the wrong location so it cannot be verified.

Attackers using Poodle forward "man-in-the-middle" script code to a website and then flood the server with an extremely large number of nearly identical HTTPS requests, which the browser automatically serves with the corresponding cookies. The attacker knows which of the encrypted blocks contains the cookie in question, although he cannot yet decrypt it. However, being the man in the middle, the attacker can copy this block to the end of the SSL data, where the encrypted padding actually takes place.

If the last byte in the decoded state is now the correct length, the remote station accepts the processed data. This value shows the remote station the MAC position. If the server receives a data packet, an attacker can infer that the cookie byte has this meaning. Much more can be done: if an attacker slightly changes HTTPS requests, he can easily determine all the bytes of the cookie.

The entire SSLv3 connection cannot be decrypted using Poodle, but the parts that can be selected on a byte-by-byte basis can. However, public user sessions in particular can be hijacked using a session cookie from HTTPS connections, and the entire user account can then be hijacked. You can imagine what could come of this.

The most effective defense against a Poodle attack is very simple: disable SSLv3 - this is a long-outdated version of the protocol that is no longer needed today. In the worst case, the encrypted connection will not be established - this only applies to Internet Explorer version 6.

If you're using Firefox, type "about:config" (without quotes) in the address bar. Your browser will then perform a TLS lookup and you will set the "security.tls.version.min" parameter to 1. If this is too difficult for you - even if nothing works - consider upgrading your Firefox browser, since upgrading Firefox to version 34 Mozilla will disable SSLv3 support by default.

To protect yourself in Chrome, launch the browser with the “–ssl-version-min=tls1” command line option. To protect yourself when using Internet Explorer, go to “Internet Options” in the “Advanced” section and uncheck the “Use SSL 3.0” checkbox. Then enable TLS in versions 1.1 and 1.2.

On the server side, things are a little more complicated because theoretically you are blocking a possible target audience with the change. However, the danger is limited: remember that TLS version 1.0 has been standardized for many years - everyone, even relatively current clients, supports this standard. Only Internet Explorer 6 cannot handle TLS 1.0, but statistics show that the percentage of IE 6 users is very small.

You can check if your web server supports SSLv3 using a test. What the actual configuration looks like depends on the server. Good setup instructions can be found online. Ultimately, you can customize configurations by copying and pasting.

In the Apache configuration, you can work with the line "SSLProtocol All -SSLv3 -SSLv3". Poodle researchers advise using "TLS_FALLBACK_SCSV" to avoid reverting to outdated versions of the protocol. This will also prevent future downgrade attacks, but it is not yet possible to say which clients, servers, and libraries may be excluded.

By the way: It's not just your servers that are affected, you should also pay attention to other services such as email. You can also exclude SSLv3 or fallback options in these configurations. In Mozilla's own Seamonkey and Thunderbird products, this works the same way as in the Firefox browser.

The general reaction can be summarized as follows: SSLv3 should be disabled. However, this can lead to compatibility issues, so developers may shy away from it. The second option is SCSV rollback: this standard prevents forced downgrades of encryption protocols.

The problem is that if the connection uses SSLv3 to begin with, it remains vulnerable. This method is already integrated into OpenSSL 1.0.1j, 1.0.0o and 0.9.8zc. A new version of OpenSSL was released shortly after the Poodle vulnerability was reported and offers a workaround for SCSV.

Google also relies on SCSV, with the search engine giant recently saying it is already immune to Poodle attacks. To be on the safe side, Google wants to completely phase out SSLv3 support in the next few months. As mentioned above, Mozilla took this step in November with the new version of Firefox 34.

While Microsoft is still tight-lipped about whether SSLv3 will be removed from Internet Explorer, the Redmond-based company is also recommending disabling support for the protocol. We also agree with the following guidelines: Avoid using the insecure SSLv3 protocol and you can rest assured that you are protected from Poodle.

SSL version 3 (SSLv3) is outdated and insecure - this has been clear since Poodle at the latest. The Internet Engineering Task Force (IETF) is currently responding with RFC 7568, which prohibits the use of the encryption protocol once developed by Netscape.

The white paper clearly states that neither clients should offer the legacy protocol nor servers should accept it. This recommendation includes contributions from Google, Mozilla and the French research institute Inria.

According to experts, numerous websites and programs have already disabled the protocol, but it is important to remove the protocol completely to avoid similar scenarios from happening again. After all, SSLv3 has been around since 1996. The successors are TLS protocol versions 1.0, 1.1 and 1.2, modified by the IETF. SSLv3 also does not have any extensions that provide modern features and are needed for today's security requirements.

Mainton Company - custom software development and testing, SEO and online advertising since 2004.