SSL3 "POODLE" Vulnerability

  • 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?


    Might want to add to the refs. A particularly clear read as usual on Langley's blog.

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

    Is "Disable SSL 3.0 support in the client" something that ordinary users can easily do, or something that would require a change in the software?

    @RickyDemer As a user you can configure that in your browser. But don't ask for a user friendly way. See

    At least _Firefox_ has a user friendly way (described in that answer).

    "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.'

    "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

    I'm still somewhat confused. Does the attacker also have to vary the request in order to vary the final byte of the final block (aside from the padding block) until that final byte XOR the cookie byte in question is equal to 7? And is there a reason you said the last cookie byte, or can it work on any byte of the cookie if the attacker arranges things so that byte ends a block?

    *"Disable support for CBC-based cipher suites"* - A list of *which* ciphers run in CBC mode would be nice to help decide what to disable.

    Check if SSL 3.0 is enabled on your server at

    What about the forced/unsafe _out of protocol_ downgrade to SSLv3? What are the software affected by that?

    @Tomalak: cipher suites have symbolic names like `SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA`; see the list for SSL 3.0 in RFC 6101. The cipher suites that use CBC are exactly those that contain "CBC" in their name.

    @ThomasPornin No ciphers don't have the string "CBC" in the FireFox "about://config" page, that's why I asked.

    One option is to use the new SSL extension (TLS_FALLBACK_SCSV) to prevent connections from being forcibly downgraded to SSLv3; this means you don't have to disable SSLv3 entirely, in case you need to connect to a server that doesn't support anything above SSLv3. But if you make a connection to that server, aren't you still vulnerable?

    @ThomasPornin, what motivates you to write such amazing and detailed answers -seriously?

    @MatthewPeters: I like to write. Writing makes more sense when there are readers.

    The SSL 3.0 symmetric cipher that doesn't use CBC mode is RC4, which may well be disabled for reasons also well explained by Thomas (and the NULL "cipher") -

    Might want to adjust this phrasing: `The "Poodle" vulnerability is an attack on the SSL 3.0 protocol released on October 14th, 2014.` Initially I thought this meant that the vulnerable protocol was released Oct 14th, 2014, and I figured that since no day-old protocol could possibly be widespread, I don't have to do anything...

    @cpast Yes, the attacker needs to vary the request. This is very easy to do though, because there are often parameters in the HTTP headers that come before the cookie that can be varied.

    your "in a nutshell" is very long and confusing, and takes a while to get to the point. Perhaps distill it or unlabel it as a nutshell?

    @ThomasPornin, in your description, you mention the previous encrypted block is e0-e7. But then you say c0 is XOR'd with e0. How can there be an encryption block "previous" to the 0th' block of cipher? I think the answer is e0 is the Initialization Vector, but I wanted to ask to be sure. In your explanation of "What enters 3DES", is e0 the IV?

    @Eddie: in CBC, whenever a block is encrypted, it is first XORed with the result of the encryption of the previous block. Since the first block does not have a "previous block", the IV is used. (In the case of SSL 3.0, the IV for a record is the last encrypted block of the previous record, and the very first IV is generated from the key exchange mechanism at the same time as the encryption key.)

    @ThomasPornin, Btw, are you from IETF?

    No. The reference to IETF in the draft and RFC 6979 is generic; it comes in "automatically" when submitting an informational RFC.

License under CC-BY-SA with attribution

Content dated before 6/26/2020 9:53 AM