So the last weeks have been rather hectic behind the scenes in the browser security world, when Google security group found a new way to exploit a rather well known design weakness in SSLv3 published in the paper This POODLE Bites: Exploiting The SSL 3.0 Fallback.

You might wonder why that would be serious, when most servers (more than 99%) today use TLS 1.0 and above (which is the version above SSLv3). The simple reason is bad implementations of the version negotiation handling in many SSL/TLS servers.

The SSL/TLS version negotiation problem

A negotiation starts out with the client sending a “client hello” saying “I’m version such and such, I’ve got these encryption ciphers” and some other info. The server side should now respond with a “server hello” message choosing the highest version of SSL/TLS that both the client and server supports. However, some bad implementations will not handle the higher version client hello and simply shut down the connection, or they will respond with “hey, I know that version” even if they don’t. Either way, the result is often that the connection is simply closed down. Note that this is especially a problem with SSLv3 implementations, but is also as known problem for TLS servers.

The client now has a problem: Was the connection closed due to connection problems, bad negotiation, or in the worst case, an attacker going in the middle and cutting the connection?

The strategy all browsers have implemented to handle this, is to downgrade the TLS version if the connection is cut during the handshake. So, typically the browser starts out with offering TLS 1.2. If server behaves properly, we’ll end up on a version between SSLv3 and TLS 1.2. If the connection is closed, the browser retries with TLS 1.1, then TLS 1.0, and finally SSLv3.

An attacker can use this to cut the connection over and over to get to the version desired. The result is that any security problem in SSLv3 actually affects all TLS servers, as long as they continue to support SSLv3. Sadly, most servers still support SSLv3 for compatibility reasons.

The result is that to be compatible with a few SSLv3 servers, most client and servers are vulnerable, due to an SSL version that should have been replaced 14 years ago when TLS 1.0 was released.

On to the actual attack on SSLv3.

It’s a combination of several weaknesses and the special behavior of browsers that makes this attack possible.

The types of encryption ciphers that are attacked are called block ciphers, such as AES and 3DES. What’s special about block ciphers, are that they can only encrypt and decrypt blocks of data. So AES takes 16 bytes and 3DES takes 8 bytes. To enable encrypting other lengths than multiples of 16 and 8, padding is applied to the end of each data record (the structure in which SSL sends encrypted data). The padding scheme is simple. Before encryption happens, the last byte in the last block contains the number of bytes that must be discarded from the plaintext after decryption.

Thus, if the length of the plaintext is known, the last byte in the last block in a ssl record is also known, which we can call the pad length byte.

If the message sent is exactly a multiple of the cipher’s block length, the last block will only contain padding, and the pad length byte will be block length – 1. This would be 7 for 3DES and 15 for AES cipher. We assume the AES cipher in the rest of this post

More importantly, a message authentication code (MAC) is added at the end of the plaintext, before the padding. If the pad length byte is wrong, the server will locate the MAC at the wrong position. If this happens, the server detects that something is wrong and closes the connection.

This can be used by the attacker to perform something called a padding oracle attack. If the attacker – sitting between the client and server – is able to make sure the client only sends records of such lengths that the last block only is padding, the attacker can replace the last block of ciphertext (which is just padding) with a previous ciphertext encrypted with the same key (any previous block the attacker has observed, one of which is hopefully has the number “15” in the last byte). If the server accepts the data, the attacker now knows that this encrypted block was decrypted to something with 15 in the last byte. Thus, the server acts as an oracle, saying yes or no to your guesses. If this cipher text that was substituted into the last block was the http cookie used to authenticate you to the server, the attacker now has one byte of your secret.

Decrypting all of it

If this was the whole story, you would only know when 15 existed in certain places in the plaintext. We’ve omitted a few details though. To strengthen the encryption scheme, the block cipher is organized in a mode called cipher block chaining (CBC) mode combined with a random initialization vector (IV). All you need to know about this mode is that the same plaintext will look totally different every time it’s encrypted. Likewise, the output of the decryption algorithm will be different each time for the same ciphertext. To recover the actual plaintext, some extra computation is needed. That’s normally a good thing. However, in this case it makes it all much worse. It means that the same encrypted cookie block will be decrypted to a different plaintext depending on the random IV and which position the block has in the record. If the last byte in the block happens to be decrypted to 15, the server accepts. Thus, the attacker can try again and again with the same cookie block until the server accepts it; that is, when the pad byte is decrypted to 15. Using some weaknesses in the CBC mode design, the attacker can now easily calculate the original cookie byte.

If you are looking for the really gritty details, it can be calculated according to this formula:
P(i) [15] = 15 ⊕ C(n­-1) [15] ⊕ C(i­-1) [15], where P(i) [15] means the 15’th byte in plaintext block i, C is the ciphertext, i is the block containing the cookie byte, and n-1 is the last block in the record containing the padding. Note how the plaintext is computed from known ciphertext only.

From this we see that it possible, if the plaintext has a certain length, to decrypt one byte of the cookie. However, we would like the whole cookie.

The BEAST

Now a technique from the BEAST attack comes into play. This was a new kind of attack against browsers that showed how easy it is to perform chosen and known plaintext attacks. In these attacks, the attacker is able to choose or know parts of the plain text that are encrypted. The goal is then to decrypt unknown parts.

How can this be done? Well, when the browser sends a request to a server, and if the server has set a cookie, this cookie is always attached to the request, no matter from which site it is issued. This means that if the attackers either fool you into visiting their server, or the simply replaces content sent to you on an unencrypted connection (say, when you read your favorite online news magazine), they can include a JavaScript that issues requests to a server that you are logged into. It doesn’t matter that the requests are issued from a different page, the browser will attach the cookie.

Thus JavaScript can, by changing the length of the URL, and data sent in the body of the request, make sure that all bytes of the cookie now can end up in last byte of an encryption block such that it can be decrypted.

How many trials are needed? Since each byte can hold 256 values, we need around 256 requests on average to decrypt one byte. Multiply that with the number of bytes in the cookie, and you have the answer. Most often, this attack can be done in seconds or minutes.

TLS is not vulnerable to this attack, as it requires that all bytes in the padding is set to the pad length byte. Thus the attacker must match all 16 bytes in the block, which is not feasible.

Splitting poodles and other countermeasures

There are several options to counteract this attack.

First option is to simply turn off SSLv3 support in the browser. This is what we will do in a relatively short time, but not right away as there are still some SSLv3 servers out there, and we’ll give them a final chance to update.

Next is to turn off the connection fallback to SSLv3. We have been tested this mode out, but found that it broke a number of servers, so will also hold a bit back on this.

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 effect.

Our products on IOS use the SSL stack provided by the OS, so there we need to wait for updates from Apple. Mini clients are not affected by this issue, so no updates needed there.

At Opera, we also have a big server park. At the time of this posting we have patched all main servers, and we will be patching the remaining systems shortly.

Finally, Opera 12 on desktop is taking the lead with disabling SSLv3 support! Since we are not able to apply the countermeasure to all of the remaining Opera 12 installations (and it also does not support TLS_FALLBACK_SCSV), we have remotely turned off SSLv3. This will be automatically distributed to all Opera 12 desktop installations in the next few days. We’re allowing ourselves to be a bit experimental with this, so users who have not yet upgraded to Opera 25 may see more of the broken servers, and we will get some experience in turning off SSLv3. Opera Classic on Android will also be updated in the next coming days.

Disclaimer: No real poodles were harmed in the development of the poodle-split countermeasure.

---