Poodle Bites TLS

Ivan Ristic
Ivan Ristic
- 3 min read

Last updated on: September 6, 2020

There’s a new SSL/TLS problem being announced today and it’s likely to affect some of the most popular web sites in the world, owing largely to the popularity of F5 load balancers and the fact that these devices are impacted. There are other devices known to be affected, and it’s possible that the same flaw is present in some SSL/TLS stacks. We will learn more in the following days.

If you want to stop reading here, take these steps: 1) check your web site using the SSL Labs test; 2) if vulnerable, apply the patch provided by your vendor. As problems go, this one should be easy to fix.

Today’s announcement is actually about the POODLE attack (disclosed two months ago, in October) repurposed to attack TLS. If you recall, SSL 3 doesn’t require its padding to be in any particular format (except for the last byte, the length), opening itself to attacks by active network attackers. However, even though TLS is very strict about how its padding is formatted, it turns out that some TLS implementations omit to check the padding structure after decryption. Such implementations are vulnerable to the POODLE attack even with TLS.

The impact of this problem is similar to that of POODLE, with the attack being slightly easier to execute–no need to downgrade modern clients down to SSL 3 first, TLS 1.2 will do just fine. The main target are browsers, because the attacker must inject malicious JavaScript to initiate the attack. A successful attack will use about 256 requests to uncover one cookie character, or only 4096 requests for a 16-character cookie. This makes the attack quite practical.

According to our most recent SSL Pulse scan (which hasn’t been published yet), about 10% of the servers are vulnerable to the POODLE attack against TLS.

Update (13 Aug 2015): A new POODLE TLS variant was disclosed in July 2015. SSL Labs will detect it starting with version 1.19.33, which was deployed in production in 1 August 2015. For more information refer to this blog post.

For more information, head to one of these resources:

I’ll keep this post up-to-date as new information becomes available. Thanks to j-mailor for sending me links to new advisories as they appear.

Show Comments (42)

Comments

Your email address will not be published. Required fields are marked *

  3. Ummm.  Er…  I just clicked on Adam Langley’s link:

    ———————-

    Secure Connection Failed

    An error occurred during a connection to http://www.imperialviolet.org. Peer attempted old style (potentially vulnerable) handshake. (Error code: ssl_error_unsafe_negotiation)

    The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.

        Please contact the website owners to inform them of this problem.

    ———————–

    Look, I’m sorry.  What K-Meleon is trying to say is it (K-M) doesn’t have SSL any more, can’t load the site.

    Gordon.

    Reply to Gordon

    1. RC4 is a Stream cipher POODLE specifically targets CBC (Block Cipher) encryption protocols. RC4 is not vulnerable to POODLE in the same way that you can’t get a DUI while walking, it is fundamentally a different mode of transportation. However, I do not recommend RC4 as it places you at similar risk due to known vulnerabilities in RC4. Instead the manufacture has provided a patch to fix the vulnerability as TLS is not vulnerable in the same way as SSL was to the attack. The patch forces the TLS server to check padding length which it is not configured to, this utilizes the TLS protection against a padding oracle attack. Unlike the SSL version of POODLE this POODLE is not a problem in the protocol it is a problem in the way some TLS servers implement the protocol.

      Reply to Carl

        1. In your case you are telling the browser that you prefer RC4 not that you require it, an attacker can still force the client to use a vulnerable cipher if it is in your cipher list. You would need to remove all CBC ciphers from your list which could severely limit browser comparability. If you are running a vulnerable version of LTM it would be recommended to patch.

          Reply to Carl

    1. From my understanding it’s needed in order to control what the client HTTP requests should look like, observe what they actually look like encrypted on the wire and use this to base your guesses on. It’s not like POODLE exposes the encryption keys of the session as a whole. You may be able to extract certain bits of information/characters this way, but without knowing what to expect, it’s difficult for the attacker to know what he actually extracted there.

      This is also mentioned in the original SSLv3 POODLE article:

      SSL 3 is dead, killed by the POODLE attack

      In order to successfully exploit POODLE the attacker must be able to inject malicious JavaScript into the victim’s browser and also be able to observe and manipulate encrypted network traffic on the wire.

      [..]

      Because the attacker controls the requests (via JavaScript) they are able to guess one character at a time.

      Reply to noneofthat

      1. The JavaScript is for sending predictable requests to the server. However, it is not required if the requests are similar or predictable, see AJAX, the attacker has a one in 256 chance in getting the IV (initiation vector) needed to decrypt the next block. The reason for this is SSL just places padding in any space required to fill out block.length, the issue is the IV which can be used to decrypt the next block.

        "Note: With CBC, the initialization vector (IV) for the first record

          is provided by the handshake protocol. The IV for subsequent records

          is the last ciphertext block from the previous record."

        – IETF SSL v.3 RFC [page 17] http://www.rfc-base.org/txt/rfc-6101.txt

        So while yes having 2 matching messages makes life significantly easier an attacker with enough similar traffic the attacker would be able to get a working IV without JavaScript or tripping the unsecured content warning. Ivan Ristic you might want to change the wording on your articles from "must inject malicious JavaScript" to something along the lines of, "clients with JavaScript enabled are at increased risk as an attacker can leverage it in an attack." A padding oracle attack doesn’t actually care about javascript it just leverages it. Services like twitter (https://community.qualys.com/blogs/securitylabs/2014/10/15/ssl-3-is-dead-killed-by-the-poodle-attack) could actually be effected if the attacker had enough similar data. Feel free to PM me if you want to chat about more technical details.

        Reply to Carl

  7. What determines if the flaw exists in different TLS implementations? I ran my site against the /ssllabs site scan and it returned a "No" for "Poodle (TLS)", which I assume means not vulnerable. I have done nothing to my site and have both TLSv1.0 and 1.2 ciphers enabled. Is it as simple as mine is not omitting the padding length check/structure after decryption or is it more to it, like having a certain version of OpenSSL?

    Reply to user5309

    1. Is it as simple as mine is not omitting the padding length check/structure after decryption or is it more to it, like having a certain version of OpenSSL?

      This time with POODLE against TLS, it is not due to a general protocol design weakness, but because of specific flawed software implementations (e.g. the mentioned F5 load balancers terminating SSL/TLS). It seems they just ported certain functions from their SSLv3 code over to TLS, without considering the improved CBC padding specifications introduced with TLS that are supposed to prevent attacks like POODLE.

      Reply to noneofthat

  8. I see the TLS Poodle flaw reported on several of my companies sites. The TLS connection for these sites are NOT terminated on either F5 or A10 loadbalancers.

    Is anything known about this issue on other implementations or could this be a false positive.

    Reply to nonmetal

      1. nonmetal wrote:

        I see the TLS Poodle flaw reported on several of my companies sites. The TLS connection for these sites are NOT terminated on either F5 or A10 loadbalancers.

        Is anything known about this issue on other implementations or could this be a false positive.

        and

        QM_SSJ4 wrote:

        I am also seeing QID 38604 detected on several of my sites after a nightly scan but NONE of them checked with SSL Labs manually is showing as vulnerable (POODLE (TLS) No. Which is correct?

        Take a look at noneofthat's post, it explains how some TLS sites are vulnerable and some are not. Basically F5 and A10 LBs are known to be vulnerable to this as their code was ported badly and still reflects SSL v3. If anyone reading this is thinking of writing their own crypto, this is the reason for the number one rule of crypto "Don’t write your own".

        Reply to Carl

  9. To get the cookie of a  logged in user, the javascript would have to wait until after a successful login (assuming the site changes the cookie after login)  then try to get the browser to send repeated requests, right?

    Q1. does the malicious js from the malicious site need to defeat the cross domain policy to get the browser to send the requests to the target site?

    Q2. wouldn’t the user see rejected requests from the server for incorrect IV values?

    Reply to jweiler

    1. So POODLE is not a web application level vulnerability getting a cookie is only one thing you can do with it. A padding oracle attack is designed to crack encryption not expose vulnerabilities in the application. In this case you are attacking the pipe not the contents of the pipe. The "malicious JavaScript" is to increase the predictable packets not to expose any other data. The repeated requests are part of the POODLE attack on the TLS protocol itself.

      Jim Weiler wrote:

      Q1. does the malicious js from the malicious site need to defeat the cross domain policy to get the browser to send the requests to the target site?

      Q2. wouldn’t the user see rejected requests from the server for incorrect IV values?

      A1. the malicious js from the malicious site doesn’t need to defeat the cross domain policy because it doesn’t need to interact with the data is just needs to make the request predictable. Its the same thing as when your application calls information from a CDN only in this case the CDN is the victim application, all you’re doing is putting data down the pipe.

      A2. only if the browser was told to, if the request is empty or doesn’t contain any displayable information the user wouldn’t have any visual issues. They might however see an increase in traffic. All the more reason to not use JS and just collect more data, unless that’s not an option.

      Reply to Carl

      1. I understand it’s not an application vulnerability. I thought the purpose of the attack was to decrypt specific sensitive data in the pipe, like an authentication cookie or credit card number. Requests containing that type of data generally have a visual component, so even if the javascript is crafted for a particular site and knows how to move the cookie or credit number to an encryption block boundary, wouldn’t  the browser display some error page returned from the server for every incorrect request?

        Reply to jweiler

        1. You’re actually really close the purpose is to decrypt sensitive data in the pipe, however, the padding oracle attack doesn’t target anything specific like a auth cookie or CC number. A javascript variation of the attack would be strictly to provide predictable data, the attacker would use this to side channel the encryption easier. At no point in the attack does the JS target a sensitive value. Once the chain is cracked later blocks can be decrypted using the IV from the previous block, and again the JS is completely optional POODLE can technically be executed without the predictable request. As for error pages, yes if the JS made a request that returned an error page the browser would show it, however that would be dependent on the JS request. For example if the attacker used xmlhttp.open("GET","ajax_info.txt",true); in the request and repeated it the browser would send an AJAX request and when it 404’d there would be no warning to the user.

          Reply to Carl

  11. Question: We own several Cisco ASA appliances, which are known to be vulnerable to Poodle, at least SSLv3. But the Qualys Scanner also reports a TLSv1 vulnerability.

    Can you explain how you detect these or is this a false positive?

    UPDATE 2012-12-16 14:16 CET:  To answer myself: Today Cisco released a Security notice http://tools.cisco.com/security/center/content/CiscoSecurityNotice/CVE-2014-8730

    But they avoid to mention the term POODLE :-x

    Reply to Jörg

    1. Jörg Friedrich wrote:

      Question: We own several Cisco ASA appliances, which are known to be vulnerable to Poodle, at least SSLv3. But the Qualys Scanner also reports a TLSv1 vulnerability.

      Can you explain how you detect these or is this a false positive?

      UPDATE 2012-12-16 14:16 CET:  To answer myself: Today Cisco released a Security notice http://tools.cisco.com/security/center/content/CiscoSecurityNotice/CVE-2014-8730

      But they avoid to mention the term POODLE :-x

      Sorry for the late reply, I’ve talked about it in more depth above but POODLE is a specific attack for TLS v. 1.0 that downgrades to SSL v.3 so technically POODLE doesn’t effect TLS v. 1.x. That said if your vendor didn’t correctly port SSL than TLS is vulnerable to a padding oracle attack.

      Reply to Carl

  12. What does the SSL Labs test actually check for? Reason I ask is I have an openssl based product which is saying it is vulnerable to "POODLE (TLS)", however it is my understanding that this is an NSS flaw which is not used in the product but is still being flagged as vulnerable.

    Any help would be greatly appreciated.

    Reply to Derek

  15. Regarding Ivan Ristic 's note:

    Microsoft – We’ve seen reports that some older platforms (e.g., Windows 2008) appear vulnerable, but no apparent patterns or reliable information so far.

    for what it’s worth – what happened at one of our customers site:

    On Feb 12, ssllabs server test reported this for a MS Windows 2008 R2 server where they just had (correctly) removed SSLv3 support; so "POODLE (SSLv3)" was gone, but now the test reported vulnerable to "POODLE (TLS)".

    I noticed, they had not installed MS14-066 (related to Schannel) and advised them to do so.

    They installed the patch today and now "POODLE (TLS)" is gone…

    Reply to Stevie

  16. An update for the Cisco ACE 10/20 & 30 modules. Cisco claims that the ACE 10 & 20 are vulnerable however the ACE30  is not: https://tools.cisco.com/bugsearch/bug/CSCus09311/?referring_site=ss

    Symptoms:
    Cisco ACE10 and Cisco ACE20 include a version of TLS that is affected by the vulnerabilities identified by the following Common Vulnerability and Exposures (CVE) IDs: CVE-2014-8730

    The impact of this vulnerability is hardware dependent.
    Cisco ACE Software running on Cisco ACE Application Control Engine ACE20 Module and Cisco ACE Application Control Engine ACE10 Module is vulnerable to this vulnerability.

    Cisco ACE Software running Cisco ACE Application Control Engine ACE30 Module is NOT affected by this vulnerability

    Note: Both Cisco ACE 10 and ACE 20 reached end of software and hardware maintenance.

    Reply to Tim

    1. Another forum member alerted to this. Cisco have since acknowledged that there is a bug though they don’t see how it can be exploited, See this URL if you have access. It is dated 7th of August. Expect a new ACE release at the end of August – A5(3.3):

      https://tools.cisco.com/bugsearch/bug/CSCuv33150/?referring_site=ss

      Symptom:
      On 14/7/15 a researcher published an article mentioning that ACE30 and 4710 could be vulnerable to a variant of Poodle TLS where only the first byte of the padding is not checked

      This is due to a issue in the Cavium SDK used in these products. While this has not been found practically exploitable, Cisco will incorporate Cavium patch to harden the Cisco ACE.

      The fix will be included in release 5.3.3 available in late August.

      The public post is available at:

      https://vivaldi.net/en-US/blogs/entry/there-are-more-poodles-in-the-forest

      Conditions:

      none

      Kind regards,

      Tim

      Reply to Tim
    • Microsoft – We’ve seen reports that some older platforms (e.g., Windows 2008) appear vulnerable, but no apparent patterns or reliable information so far.

    I did a bunch of testing, scanning various versions of Windows + IIS with the SSL Labs test. It seems all versions of Windows NT 4.0 to 2008 R2 were vulnerable. It looks like it was first fixed in MS12-049, from July 2012, which fixes Windows 2003, 2008, and 2008 R2. The wording of the Microsoft bulletin is interesting:

    This security update resolves a publicly disclosed vulnerability in TLS. The vulnerability could allow information disclosure if an attacker intercepts encrypted web traffic served from an affected system. All cipher suites that do not use CBC mode are not affected.

    It makes me wonder if they were aware of this specific vulnerability in 2012, or if fixing some other bug also happened to fix this issue.

    The MS14-066 Schannel patch also contains this fix, which means any Windows server which is vulnerable to POODLE over TLS is also vulnerable to remote code execution. There does not seem to be any fix for Windows NT or 2000. Windows 2012 and newer do not appear to be vulnerable.

    Reply to Tom