Canonical question regarding the recently disclosed padding oracle vulnerability in SSL v3. Other identical or significantly similar questions should be closed as a duplicate of this one.

  • What is the POODLE vulnerability?
  • I use [product/browser]. Am I affected?
  • Is [product] vulnerable to the POODLE attack?
  • What do I need to do to secure my [product] with respect to this vulnerability?
  • How do I detect POODLE attacks on my network?
  • Are there any known POODLE attacks?



4 Answers 4


What is the Poodle vulnerability ?

The "Poodle" vulnerability, released on October 14th, 2014, is an attack on the SSL 3.0 protocol. It is a protocol flaw, not an implementation issue; every implementation of SSL 3.0 suffers from it. Please note that we are talking about the old SSL 3.0, not TLS 1.0 or later. The TLS versions are not affected (neither is DTLS).

In a nutshell: when SSL 3.0 uses a block cipher in CBC mode, the encryption process for a record uses padding so that the data length is a multiple of the block size. For instance, suppose that 3DES is used, with 8-byte blocks. A MAC is computed over the record data (and the record sequence number, and some other header data) and appended to the data. Then 1 to 8 bytes are appended, so that the total length is a multiple of 8. Moreover, if n bytes are added at that step, then the last of these bytes must have value n-1. This is made so that decryption works.

Consider the decryption of a record: 3DES-CBC decryption is applied, then the very last byte is inspected: it should contain a value between 0 and 7, and that tells us how many other bytes were added for padding. These bytes are removed, and, crucially, their contents are ignored. This is the important point: there are bytes in the record that can be changed without the recipient minding in the slightest way.

The Poodle attack works in a chosen-plaintext context, like BEAST and CRIME before it. The attacker is interested in data that gets protected with SSL, and he can:

  • inject data of their own before and after the secret value that he wants to obtain;
  • inspect, intercept and modify the resulting bytes on the wire.

The main and about only plausible scenario where such conditions are met is a Web context: the attacker runs a fake WiFi access point, and injects some Javascript of their own as part of a Web page (HTTP, not HTTPS) that the victim browses. The evil Javascript makes the browser send requests to a HTTPS site (say, a bank Web site) for which the victim's browser has a cookie. The attacker wants that cookie.

The attack proceeds byte-by-byte. The attacker's Javascript arranges for the request to be such that the last cookie byte occurs at the end of an encryption block (one of the 8-byte blocks of 3DES) and such that the total request length implies a full-block padding. Suppose that the last 8 cookie bytes have values c0, c1, ... c7. Upon encryption, CBC works like this:

CBC encryption, from Wikipedia

So if the previous encrypted block is e0, e1, ... e7, then what enters 3DES is c0 XOR e0, c1 XOR e1, ... c7 XOR e7. The ei values are known to the attacker (that's the encrypted result).

Then, the attacker, from the outside, replaces the last block of the encrypted record with a copy of the block that contains the last cookie byte. To understand what happens, you have to know how CBC decryption works:

CBC decryption (from Wikipedia)

The last ciphertext block thus gets decrypted, which yields a value ending with c7 XOR e7. That value is then XORed with the previous encrypted block. If the result ends with a byte of value 7 (that works with probability 1/256), then the padding removal step will remove the last 8 bytes, and end up with the intact cleartext and MAC, and the server will be content. Otherwise, either the last byte will not be in the 0..7 range, and the server will complain, or the last byte will be between 0 and 6, and the server will remove the wrong number of bytes, and the MAC will not match, and the server will complain. In other words, the attacker can observe the server's reaction to know whether the CBC decryption result found a 7, or something else. When a 7 is obtained, the last cookie byte is immediately revealed.

When the last cookie byte is obtained, the process is executed again with the previous byte, and so on.

The core point is that SSL 3.0 is defined as ignoring the padding bytes (except the last). These bytes are not covered by the MAC and don't have any defined value.

TLS 1.0 is not vulnerable because in TLS 1.0, the protocol specifies that all padding bytes must have the same value, and libraries implementing TLS verify that these bytes have the expected values. Thus, our attacker cannot get lucky with probability 1/256 (2-8), but with probability 1/18446744073709551616 (2-64), which is substantially worse.

I use [product]. Am I affected? Is [product] vulnerable to the Poodle attack ?

The attack scenario requires the attacker to be able to inject data of their own, and to intercept the encrypted bytes. The only plausible context where such a thing happens is a Web browser, as explained above. In that case, Poodle is, like BEAST and CRIME, an attack on the client, not on the server.

If [product] is a Web browser, then you may be affected. But that also depends on the server. The protocol version used is a negotiation between client and server; SSL 3.0 will happen only if the server agrees. Thus, you might consider that your server is "vulnerable" if it allows SSL 3.0 to be used (this is technically incorrect, since the attack is client-side in a Web context, but I expect SSL-security-meters to work that way).

Conditions for the vulnerability to occur: SSL 3.0 supported, and selection of a CBC-based cipher suite (RC4 encryption has no padding, thus is not vulnerable to that specific attack -- but RC4 has other issues, of course).


  • Disable SSL 3.0 support in the client.
  • Disable SSL 3.0 support in the server.
  • Disable support for CBC-based cipher suites when using SSL 3.0 (in either client or server).
  • Implement that new SSL/TLS extension to detect when some active attacker is breaking connections to force your client and server to use SSL 3.0, even though both know TLS 1.0 or better. Both client and server must implement it.

Any of these four solutions avoids the vulnerability.

What do I need to do to secure my [product] with respect to this vulnerability?

Same as always. Your vendor publishes security fixes; install them. Install the patches. All the patches. Do that. For Poodle and for all other vulnerabilities. You cannot afford not to install them, and that is not new. You should already be doing that. If you do not install the patches then Níðhöggr will devour your spleen.

How do I detect Poodle attacks on my network?

You don't ! Since the most probable attack setup involves the attacker luring the victim on their network, not yours.

Although, on the server side, you may want to react on an inordinate amount of requests that fail on a decryption error. Not all server software will log events for such cases, but this should be within the possibilities of any decent IDS system.

Are there any known Poodle attacks?

Not to my knowledge. In fact, when you control all the external I/O of the victim, it is still considerably easier to simply lure the poor sod on a fake copy of their bank site. Cryptographic attacks are neat, but they involve more effort than exploiting the bottomless well of user's gullibility.

  • 26
    "If you do not install the patches then Níðhöggr will devour your spleen." I think that should be the new Backtrack/Kali motto. Needless to say, +1 for not only posting a freaking dissertation, but also making it... well, let's say 'easy to remember.'
    – KnightOfNi
    Commented Oct 15, 2014 at 2:05
  • 37
    "Cryptographic attacks are neat, but they involve more effort than exploiting the bottomless well of user's gullibility." I have the feeling I will be quoting this at some point.. +1 Commented Oct 15, 2014 at 2:10
  • 3
    Check if SSL 3.0 is enabled on your server at poodlebleed.com Commented Oct 15, 2014 at 6:38
  • 6
    @ThomasPornin, what motivates you to write such amazing and detailed answers -seriously? Commented Oct 15, 2014 at 14:47
  • 24
    @MatthewPeters: I like to write. Writing makes more sense when there are readers. Commented Oct 15, 2014 at 14:48

To disable SSL v3.0 support:

In Clients:

Mozilla Firefox



  • Type about:config into the navigation bar and press [Enter]
  • Accept the warning and proceed
  • Search for tls
  • Change the value of security.tls.version.min from 0 to 1 (0 = SSL 3.0; 1 = TLS 1.0)


  • Run Chrome with the following command-line flag: --ssl-version-min=tls1

Internet Explorer

  • Go to Settings -> Internet Options -> Advanced Tab -> Uncheck "SSLv3" under "Security"

In Web Servers:

Apache v2

  • Add the following line to your SSL configuration file, or edit the existing line to read: SSLProtocol All -SSLv2 -SSLv3
  • Restart the web server with sudo apache2ctl restart

Zeus Web Server

(%ZEUSHOME is the install location, usually /usr/local/zeus)

  • Upgrade to Zeus Web Server 4.3r5
  • Add the following line to %ZEUSHOME%/web/global.cfg: tuning!ssl3_allow_rehandshake never
  • Restart the web server with sudo %ZEUSHOME%/restart-zeus


  1. "POODLE Attacks on SSLv3", ImperialViolet, ImperialViolet - POODLE attacks on SSLv3

  2. "SSLv3 POODLE Vulnerability Official Release", InfoSec Handlers Diary Blog, > Internet Storm Center - Internet Security | SANS ISC

  • 1
    If you are using Opera 12.17 or older, you can press <ctrl>+<f12>, go to the tab Advanced, then on the left menu you click on Security. You will find a button saying Security protocols.... Click it, uncheck Enable SSL 3 and click OK. Now you are protected! Commented Oct 15, 2014 at 17:28
  • 1
    Also see: poodle.io
    – gsgx
    Commented Oct 16, 2014 at 0:47
  • 1
    doesn't Chrome use the same internet options as IE?
    – Nzall
    Commented Oct 16, 2014 at 11:34

I've published a blog on how to disable SSLv3 in some of the most common bowsers and server platforms (https://scotthelme.co.uk/sslv3-goes-to-the-dogs-poodle-kills-off-protocol/). This should at least help answer the question on how to fully mitigate POODLE be you a client or a server.

Below are the key details.

How to protect your server

The easiest and most robust solution to POODLE is to disable SSLv3 support on your server. This does bring with it a couple of caveats though. For web traffic, there are some legacy systems out there that won't be able to connect with anything other than SSLv3. For example, systems using IE6 and Windows XP installations without SP3, will no longer be able to communicate with any site that ditches SSLv3. According to figures released by CloudFlare, who have completely disabled SSLv3 across their entire customer estate, only a tiny fraction of their web traffic will be affected as 98.88% of Windows XP users connect with TLSv1.0 or better.


To disable SSLv3 on your Apache server you can configure it using the following, both in the SSL configuration section and in all SSL-enabled virtual hosts explicitly:

SSLProtocol All -SSLv2 -SSLv3

This will give you support for TLSv1.0, TLSv1.1 and TLSv1.2, but explicitly removes support for SSLv2 and SSLv3. Check the config and then restart Apache.

apachectl configtest

sudo service apache2 restart


Disabling SSLv3 support on NginX is also really easy.

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

Similar to the Apache config above, you will get TLSv1.0+ support and no SSL. You can check the config and restart.

sudo nginx -t

sudo service nginx restart


This one requires some registry tweaks and a server reboot but still isn't all that bad. Microsoft have a support article with the required information, but all you need to do is modify/create a registry DWORD value.

HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders \SCHANNEL\Protocols

Inside protocols you will most likely have an SSL 2.0 key already, so create SSL 3.0 alongside it if needed. Under that create a Server key and inside there a DWORD value called Enabled with value 0. Once that's done reboot the server for the changes to take effect.

IIS Settings

How to check your server

The easiest and probably the most widely used method to test anything to do with your SSL setup is the Qualys SSL Test. Simply navigate to the site, enter the domain for the website you want to test and hit submit to start the test.

Qualys Check Domain

Once the test has finished, you will get a nice summary of your results and a lot of detailed information further down the page. Specifically, you want to look in the Configuration section at your supported protocols.

Check protocols

What you want to see here is that you have no SSL protocols supported. You should have long since disabled SSLv2.0 and now we've just removed SSLv3.0 too. Supporting TLSv1.0 or better is good enough to support the absolute vast majority of internet users out there without exposing anyone to unecessary risk.

How to protect your browser

It is also possible to protect yourself from POODLE by disabling SSLv3 support in your browser. This means that even if the server does offer SSLv3 support, your browser will never use it, even during a protocol downgrade attack.


Firefox users can type about:config into their address bar and then security.tls.version.min into the search box. This will bring up the setting that needs to be changed from 0 to 1. The existing setting allows Firefox to use SSLv3 where it's available and if it's required. By changing the setting you will force Firefox to only ever use TLSv1.0 or better, which is not vulnerable to POODLE.

Firefox Settings


Chrome users don't have an option in the GUI to disable SSLv3 as Google removed it due to confusion over whether SSLv3 or TLSv1 was better with one having a higher numeric value. Instead you can add the command line flag --ssl-version-min=tls1 to enforce the use of TLS and prevent any connection using the SSL protocol. In Windows, right click on your Chrome shortcut, hit Properties and add the command line flag as seen in the image below.

Chrome Settings

If you use Google Chrome on Mac, Linux, Chrome OS or Android, you can follow these instructions here.

Internet Explorer

Fixing up Internet Explorer is also pretty easy. Go to Settings, Internet Options and click on the Advanced tab. Scroll down until you see the Use SSL 3.0 checkbox and uncheck it.

IE Settings

How to check your browser

If you want to check that your browser changes have definitely removed SSLv3.0 support there are a couple of sites that you can use. If you visit https://zmap.io/sslv3/ with SSLv3 enabled in your browser, you will see the warning message I'm getting here in Chrome where I haven't yet disabled SSLv3. To double check the site was working as expected, I disabled SSLv3 support in Internet Explorer and opened up the site there too. Here you can see the difference.

Chrome and IE test

You can also try https://www.poodletest.com/ alongside Zmap.

  • As of Firefox 34 security.tls.version.min now defaults to 1 Commented Dec 15, 2014 at 14:25

If you don't want to give away your site's name to these other websites, you can also test it with...

openssl s_client -ssl3 -host <your host name> -port 443

If it doesn't connect then you're ok.

But also make sure that your openssl is working properly with your site...

openssl s_client -host <your host name> -port 443

Disabling sslv3 also disables IE6 and Windows XP SP2 and below. Not many have IE6 but a lot still have Windows XP.

  • 3
    One may argue that people who still cling to XP have had it coming, in particular if they did not bother to install SP3. A pre-SP3 XP has been out of updates for some years; if it is used to browse the Web then it probably is already full of malware. As for IE 6.0, it can use TLS 1.0, it is just not enabled by default (it can be activated in the "Internet options" menu). Commented Oct 19, 2014 at 0:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .