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.


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.

Back to top
  • L33t4opera

    Hi Håvardi, thanks for the detailed explanation of the problem, and for the countermeasure “anti poodle record splitting”, really nice job Opera’s Security Team!

  • WOFall

    > Since each byte can hold 256 values, we need around 256 requests on average to decrypt one byte.

    Would this not rather be 256 requests worst case, 128 requests on average?

    > Finally, Opera 12 is taking the lead with disabling SSLv3 support!

    And I wonder how many users that is!

    • Håvard Molland

      Yes, normally when doing brute force you need to go through half of the possible values in average .

      However, in this case the cipher works as a random generator, so we are not going through the guesses in a controlled way, and we might test with the same number many times.

      Thus, it’s like throwing a dice. To hit a 5, I sometimes need to roll the dice once, other times I need 10 trials. In average I need 6 trials.

      On the other hand I only need on average 3 guesses to guess what number between 1 and 6 someone is thinking of. See the difference?

  • x a

    Thanks, Håvard, for the comprehensive sum up of the issue.

  • :knight: in a anti poodle suit

    Good to know there is a splitting defense

  • M Karlsson

    In Opera 12 I’ve disabled SSL3 manually (can’t find settings in Opera 26 though), what I wonder is how this distribution to Opera 12 will take place. As a normal upgrade to 12.18? Will Opera on Apple App Store be updated as well, I think it is still 12.15. Opera Mini doesn’t seem vulnerable (I guess you can also stop SSL3 for it on your servers), what about other versions of Opera for mobiles?

    BTW, good to see sync reappearing, it’s vital for me as I use Opera cross platform (Win, OSX, Linux, Android) and I’m still at 12.x for most of the time.

    • Helge Andre Gjølme

      It’s a small preference file sent out from autoupdate, it should be invisible.
      There will be no binary update.

    • tarquinwj

      The article has now been updated with comments about other products.

  • Ra-Mon

    Thank you for the explanation !
    So you confirm that the reporting Opera Dev’ 26 to be “Vulnerable” to Poodle Attack is FALSE ?

    • Håvard Molland only detects if you have SSLv3 enabled or not. It does not detect the anti poodle record splitting (APRS) counter measure. Thus it is jumping to conclusion a bit too fast. However, even with APRS we really want to get rid of SSLv3 as soon as possible, so we will follow the other browsers in turning it off soon. Thus, APRS is just a temporary solution to keep you secure until then.

      Also note that Opera is the only browser who has released the APRS in a stable release. Our testing shows us that it will not lead to compatibility problems, while other browsers wanted more testing in beta releases.

  • rseiler

    I wish I’d seen this article earlier, since 12.17 has been crashing on me (I use Win 8.1) like crazy the last couple days (and only the last couple days). Eventually, I noticed the repeated changes in the SSL/TLS settings, and that had me baffled until I read this article.

    I don’t whether it’s the disabling of SSL 3 or the enabling of TLS 1.1/1.2 that does it, but one or the other makes Opera extremely unstable. I’ve turned off autoupdating for now, which I hope is a way to stop this. If it isn’t, please let me know what server I can block in the firewall.

    • rseiler

      Sadly, disabling updates does NOT do the trick; the settings still magically change, even in the midst of a session.

      • Håvard Molland

        If you manually change the tls settings through opera:config, the Opera 12.17 update system will leave them alone. For example opera:config#SecurityPrefs|EnableTLSv1.1.

        We have not seen these issues before though. What sites are crashing? Have you tried with a clean profile? It might be that other settings are influencing this.

        Also, Opera 12.17 has in reality, apart from minor fixes, not been updated for almost two years, and is getting outdated. Our recommendation is to upgrade to latest version, which at this point is Opera 25.

        • unstandable

          I was having the same repeated crashing problem since this change was made using 12.17 on Windows 8.1. I was able to stop the crashing by enabling SSL and disabling TLS 1.1 and 1.2.

          • rseiler

            A compromise setting that hasn’t crashed here is all disabled except TLS 1. So it seems that it’s not the disabling of SSL 3 that’s the culprit but rather the enabling of 1.1 and 1.2 (not sure yet if having just 1.0 and 1.1 on would work, but I’m trying that next).

        • sgrandin

          I’d be glad to upgrade to O25 when it becomes a full-funtion browser. It’s still very much in the developmental stage. Perhaps that’s why a large proportion, if not the majority of Opera users are still with 12.

        • starkcitizen

          I also had this ridiculous crashing for almost a week!!! Also couldn’t login to I’ve disabled TLS 1.1 and 1.2 and for now it’s good. Opera 25 lack features, development is much too slow. There should be vertical thumbnail tabs, keywords in bookmarks and autorefreshing speed dial thumbnails to say the least.

        • thiscall

          Opera 12 has been crashing for me for almost a year since i installed it freshly on Windows 8. And now i know why,i preemptively disabled SSL3 and enabled TLS 1.1/1.2 myself.

          It crashes absolutely at random, leaves no crashdumps no nothing. It was a real mindcracker. *Really* annoying too.

          If devs at Opera could release a patch for the 12 as they did with Heartbleed that’d be really sweet.
          Although i’ll understand though if they can’t due to company policies, time constaints and whatnot.

          Still planning on using 12 for at least another year.

          • rseiler

            That’s brutal! Congratulations on your level of patience though.

            Just to follow-up, SSL3-off/TLS1-on is stable. Experimentation with other TLS’s though showed the same crashes, so I’m going to be satisfied with TLS1.

  • Menelmacar

    Nice that you did that for Opera 12. If you’re in a mood to solve Opera 12 security problems, it would also be nice if you followed that up by solving the continuing security problem that (since the end of September) Opera 12 various users have had to disable the “OCSP Validate Certificates” option in [opera:config], because OCSP validation has stopped working for many websites.

    Typical error message:

    “Secure connection: fatal error (1066)

    [address of site]

    Unable to verify the website’s identity (OCSP error).

    The response from the online certificate validation (OCSP) server was too old.”

    See and (This happens for me even if a site uses OCSP stapling, so an inquiry to a separate OCSP server should NOT be necessary. )

    • rseiler

      I’d second that request. And as I mentioned in one of those threads, disabling OCSP doesn’t solve a variant on the problem with some Universal SSL sites. Those sites are dead to Opera entirely.

    • Håvard Molland

      We have seen these OCSP issues too. However, they are not security problems, and are actually not Opera bugs at all, at least not the ones we have analyzed. Opera implemented OCSP stapling (OCSP stapling means that revocation info is ‘stapled’ into the TLS handshake) long before any one else, and first now websites are starting to use them. Sadly, they often do it wrong, and they send outdated OCSP’s. Thus, you probably will see that the site sometimes works and sometimes not.
      The reason you don’t see this in other browsers is that I believe Opera 12 is the only browser that checks OCSP stapling.

      If we had actively maintained Opera 12.17, we would probably have adopted as we often (sadly) have to, and made our OCSP stapling checking a bit more laxed. We don’t have any config setting for turning off OCSP at this point. Turning off OCSP should be OK, as CRL revocation would be used instead.

      When it comes to, it seems that they are using a GCM mode block cipher along with elliptic curve cryptograpgy, a cipher combination Opera 12.17 doesn’t support, and never will since we no longer add new futures to Opera 12.17.

      • Yea, I took a bug report about this. But why did it worked with Opera 8.54 in 2007? oO

        • rseiler

          You read my mind; I was just about to ask that!

          Someone pointed that out in the thread linked above. Opera 8.54 supported ECDSA? And IE7?! I hope Cloudflare’s UniversalSLL, which is what’s causing this, doesn’t get popular.

      • Eion Robb

        There’s still a large following of Opera 12 users who aren’t happy with the switch to webkit. How about open-sourcing old Opera 12 so that the community can add support for ECDSA?

  • sgrandin

    I’m wondering if this could be the cause of random crashes I’m getting with 12.17 since about a week ago. The crash box shows not only websites, but also the Speed Dial as the point of stopping.

  • I have the latest version of Opera, and I am getting the warnings that SSLv3 is enabled!!

    Version:25.0.1614.63 – Opera is up to date
    Update stream:Stable
    System:Windows 7 64-bit (WoW64)

    • Håvard Molland

      We have not yet turned off SSLv3 in Opera 25. However we have (as the only browser) implemented anti-poodle record splitting which turns SSLv3 immune to this attack.

  • Prevedovich

    Hello! Is there any chance that Opera will add an option to turn the Site Check off?
    1. It consumes traffic even in Turbo mode
    2. All information is unencrypted
    3. You give private information to third party

    All other browsers have the option except Opera.

  • Kim

    Has this been Fixed by Opera?

  • dfhfdgt

    You disabled SSL3 in Opera 12. But why did you disabled TLS 1.1 and 1.2 too? (it also disable SHA-256 and use SHA-1 instead, so it also lower the signature algorithm)