Zombie POODLE and GOLDENDOODLE Vulnerabilities

Recently new vulnerabilities like Zombie POODLE, GOLDENDOODLE, 0-Length OpenSSL and Sleeping POODLE were published for websites that use CBC (Cipher Block Chaining) block cipher modes. These vulnerabilities are applicable only if the server uses TLS 1.2 or TLS 1.1 or TLS 1.0 with CBC cipher modes.

Update May 30, 2019: The grade change described below is now live on https://www.ssllabs.com/

SSL Labs identifies cipher suites using CBC with orange color and with text WEAK. This change won’t have any effect on the grades, as it only means that SSL Labs discourages the use of CBC-based cipher suites further.

SSL Labs will start giving “F” grade to the server affected by these vulnerabilities from end of May 2019. For now, SSL Labs will give only a warning for affected servers:

  • Zombie POODLE (Invalid padding with valid MAC)
  • GOLDENDOODLE (Valid padding with an invalid MAC)
  • 0-Length OpenSSL (Invalid Mac/Valid Pad, 0-length record)
  • Sleeping POODLE (invalid padding with valid MAC)

SSLLabs UI Changes

 

Limitation in SSL Labs Detections

  • These tests are specific to protocol/cipher suite, SSL Labs only checks with preferred Protocol and CBC Cipher suite. There is a probability that the server could be vulnerable with other set of protocol/cipher suite.
  • SSL Labs only checks with a limited set of CBC cipher suite

More Information

Update April 26, 2019: The warning is live on https://dev.ssllabs.com/ and https://www.ssllabs.com/. As stated above, the grade change will be live by the end of May.

46 responses to “Zombie POODLE and GOLDENDOODLE Vulnerabilities”

  1. There doesn’t seem to be a reference to Sleeping POODLE, nor have I easily found a paper or article on it. The description is the same as Zombie. What’s different about it?

    Thanks

    • Sleeping POODLE is similar to POODLE TLS. There is no vendor advisory for Sleeping POODLE, you can get information in Researcher’s Blackhat presentation.

      Regards,
      Yash K.S

  2. So if this is the new grading, This means for
    win2012R2 servers only
    TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) DH 2048 bits FS 256
    TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) DH 2048 bits FS 128
    and tor windows 2016 and 2019 only
    TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH secp384r1 (eq. 7680 bits RSA) FS 256
    TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH x25519 (eq. 3072 bits RSA) FS 128
    TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) DH 2048 bits FS 256
    TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) DH 2048 bits FS 128
    are considered safe.
    disabling all CBC cipher suites would mean that we are limited to to cipher suites above,
    this might conflict with some old browsers or server to server connections with 3th party companies.

    • We are only encouraging to move away from CBC based cipher suits after 4 new CBC based vulnerabilities. As of now, there is no grade change for CBC and servers can continue to use.

      Regards,
      Yash K.S

    • The concerns Bart has raised are genuine. The problem is if we disable the CBC ciphers then Internet Explorer on Windows 7 will not be able to communicate as Windows 7 does not support GCM ciphers. We raised the issue with Microsoft but they have refused to add GCM support as according to them Windows 7 is near to EOL. Only option on Win 7 is to use a different browser like Chrome or Firefox.

  3. “SSL Labs will identify cipher suites using CBC with orange color and with text WEAK”

    are there any plans to do the same thing on the client test?

  4. The downside of this change is that several ciphers are now “equally” marked “WEAK”, although their weakness is of a totally different magnitude; 3DES, any static RSA (non-FS), and now any CBC.

    Shouldn’t they be marked WEAK with a different color or score per cipher?

    • We got 4 new vulnerability based on CBC cipher, we are marking it as Orange to say it is Weak, but without a grade change. Since we got 4 new vulnerability, we are encouraging users to move away from CBC gradually.

      Regards,
      Yash K.S

  5. These newly-discovered vulnerabilities regarding CBC variable Padding oracles are pretty bad news for literally all CBC-based ciphersuites IMHO, It does no longer make sense to filter some which may not be vulnerable, but it is now time and a target for further improving TLS security, to get entirely rid of them asap.
    The tests are currently capable to deliver numerous server anaylsis results with exactly zero “good” ciphersuites being used (all marked at least “weak”).
    For my part I have tested various servers already and found out that especially not most current versions of MS-based IIS server softwares are often badly configured, concerning ciphers. This accounts also for the more complicated configurability of ciphers in the server and MS should do something about it to make this much easier. They even have not yet implemented TLS 1.3 as well into their core crypto of Windows 10 and 8.1. (what I call a really bad case of just intentional lagging around for whichever reason. It is time yet to get such in place finally, plus a complete overworking of which ciphers are now due to be implemented and which are due to be finally kicked off forever. MS also lacks chacha20 yet.)

    • There will be no Grade change even if you are using CBC ciphers, grade change applies only if Server is vulnerable.

      Regards,
      Yash K.S

      • Yash …. you made the statement to Dimitry that there will be no grade change if you are using CBC ciphers, grade change applies only if server is vulnerable but prior to that it stated that you are flagging a server as vulnerable based on protocol and cipher…so which is it? If its not by cipher/protocol, how are you determining the vulnerability?

        • John,

          This Vulnerability is applicable to a Server which uses CBC cipher. Grade will be impacted only if server uses CBC cipher + Vulnerable.

          Regards,
          Yash K.S

  6. Only to be sure, have a ZOMBIE POODLE – YES on TLS 1.2 will be a PCI-DSS fail?
    From the Qualys last update I can see that

    -QID 42366 “SSLv3.0/TLSv1.0 Protocol Weak CBC Mode Server Side Vulnerability (BEAST)”

    will be a PCI fail, but this not include TLS1.1/1.2.

  7. The article mentions that it is vulnerable when using TLS 1.2 & CBC Ciphers. Wouldn’t that make all servers vulnerable if you want legacy browser support?

    My scan states that i am not vulnerable to Zombie Poodle or GOLDENDOODLE, however I do see that I am using TLS1.2 with CBC Ciphers with IE11 & some Safari versions. Are there better Ciphers to use or are my setting secure?

    IE 11 / Win 7 R RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ECDH secp256r1 FS
    IE 11 / Win 8.1 R RSA 2048 (SHA256) TLS 1.2 > http/1.1 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ECDH secp256r1 FS
    IE 11 / Win Phone 8.1 R RSA 2048 (SHA256) TLS 1.2 > http/1.1 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 ECDH secp256r1 FS
    IE 11 / Win Phone 8.1 Update R RSA 2048 (SHA256) TLS 1.2 > http/1.1 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ECDH secp256r1 FS

    My current settings. TLS 1.0 & 1.1 are disabled.
    SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256

    • Detection of Vulnerability is not based only on TLS 1.2 + CBC, we do probing for each of these 4 vulnerability separate. More info on Payload, you can check out links of Researcher in blog.

      Regards,
      Yash K.S

    • Hi Frank,

      Unknown is the default value when the test starts and it is equivalent to Failed

      Regards,
      Nauman Shah

  8. Dear SSLLabs-Team,

    thanks a lot for all your explanations. I need some more ;-)

    Having tested a server via your website the results show the current grade A but also the warning that the server is vulnerable to Zombie POODLE and the grade will be set to F. Accordingly, some CBC-ciphers are marked as WEAK.

    Thus, using your REST-API to test the same server I would expect to find futureGrade: “F” and hasWarnings: true in the result. However, that is not the case. futureGrade is not present at all and hasWarnings is false although the same result contains zombiePoodle: 3.

    Do I misunderstand your API (https://github.com/ssllabs/ssllabs-scan/blob/master/ssllabs-api-docs-v3.md) or is futreGrade/hasWarnings just not yet implemented to be aware of These new 4 vulnerabilities? Do you have any plans to do so?

    By the way, is there any way to receive the “WEAK”-label for cyphers also via the REST API? Or do you “statically” publish a list of cyphers that you consider weak?

    Thanks a lot for your support,
    kind gegards
    -Max

  9. Hi – I’m getting this on our Citrix Netscaler, we are almost on the latest firmware.

    This server is vulnerable to the Zombie POODLE vulnerability. Grade will be set to F from May 2019. M

    Do I need to harden the netscaler or the servers? anyone?

    Thank You

  10. I have compiled openssl 1.0.2r with apache 2.4.27 and still see the vulnerabilities.

    This server is vulnerable to the Zombie POODLE vulnerability. Grade will be set to F from May 2019. MORE INFO »
    This server is vulnerable to the GOLDENDOODLE vulnerability. Grade will be set to F from May 2019. MORE INFO »
    This server is vulnerable to the OpenSSL 0-Length vulnerability. Grade will be set to F from May 2019. MORE INFO »

    Current Ciphers we are using are
    SSLCipherSuite “AES256-GCM-SHA384:AES128-GCM-SHA256:RSA+AES256+SHA256 RSA+AES128+SHA256 RSA+AES256+SHA1 RSA+AES128+SHA1”

    So if I use the above ciphers with openssl 1.0.2r compiled with apache 2.4.27 would it still stay vulnerable

  11. Given that TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 and TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 were previously declared weak: https://community.qualys.com/thread/14821, does that mean that in fact the valid cipher suite set for Windows Server 2016 is only

    TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH x25519 (eq. 3072 bits RSA) FS 256
    TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH x25519 (eq. 3072 bits RSA) FS 128

    and for windows Server 2012R2 we have… .nothing?

    • In that link, the Diffie-Hellman Key Exchange is set to 1024 bits, so it would be considered weak.

      Change it to 2048 bit to not be considered weak
      reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Diffie-Hellman /v ServerMinKeyBitLength /t REG_DWORD /d 0x00000800 /f

      It can be set up to 4096 bit as well.
      reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Diffie-Hellman /v ServerMinKeyBitLength /t REG_DWORD /d 0x00001000 /f

      TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) DH 4096 bits FS 256
      TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) DH 4096 bits FS 128

    • 2012 is left with ECDSA signed certificates, and these…

      TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384
      TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256
      TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384

      And these, though apparently P521 is too costly to recommend it’s use.
      TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P521
      TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P521

  12. Hi,
    How can I deal with this issue in this Cipher chain?

    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK 256
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK 128
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK 256
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK 128
    TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH secp256r1 (eq. 3072 bits RSA) FS 256
    TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH secp256r1 (eq. 3072 bits RSA) FS 128
    TLS_RSA_WITH_AES_256_CBC_SHA (0x35) WEAK 256
    TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) WEAK 128
    TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d) WEAK 256
    TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c) WEAK 128
    TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d) WEAK 256
    TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) WEAK 128
    TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK

    Thanks In advance

  13. In the cases of the presence of CBC ciphers (preferred or not preferred) on non-vulnerable servers, will the presence of CBC ciphers alone (whether preferred or not preferred) result in a downgrade of score after June 1, 2019 or any time in the future? If so, what will the maximum score be limited to?

    • Hi Jerry,

      There is no effect(downgrade) in grade if the server supports CBC cipher suites irrespective of their preference.
      We have not decided on future grade change for CBC cipher suites, if we have any plans then it will be conveyed to the community in advance

      Regards,
      Nauman Shah

  14. Hi,

    is there any chance to locally perform the 0-Length OpenSSL test? I’m seeing that error on an Oracle HTTP Server and in order to get Oracle support look into that we’d need a reproduction of the check,

    BR

    • I am trying to figure why OHS server is having F grade even though it does not use openSSL for TLS communication.
      Is there a way to test locally?
      Oracle is not able to provide any support without CVE numbers. What would be the CVEs mapped to this vulnerability?

  15. Hi,

    Can you explain what exactly is technically checked for 0-length openssl vulnerability? I wonder why we have this on an oracle http server which does mit use openssl at all. Can I replicate that check locally?

    Br. Johannes

  16. How to mitigate the 0-Length OpenSSL vulnerability with Citrix ADC? I’ve googled for hours using different search terms and there is nothing blindly obvious? version NS: 13.0x

  17. Question: Why do I get different results when the only difference is the underlying OS? Tomcat on CentOS 7 shows *not* vulnerable to these exploits, yet Windows Server 2012 R2 shows vulnerable. Tomcat TLS/SSL configuration is identical. Why the discrepancy? How do I mitigate them on the Windows platform when the ciphers in Tomcat are identical?

  18. I have noticed that we get different results for one of our externally exposed hosts. It seems like the SSLLabs test sometimes reports the Zombie POODLE test result as “exploitable”, and sometimes reports the same test result as “unknown”. The results are not consistent.

    e.g.

    POODLE (SSLv3) No, SSL 3 not supported (more info)
    POODLE (TLS) No (more info)
    Zombie POODLE Yes EXPLOITABLE (more info) TLS 1.2 : 0xc014
    GOLDENDOODLE No (more info) TLS 1.2 : 0xc014
    OpenSSL 0-Length No (more info) TLS 1.2 : 0xc014
    Sleeping POODLE No (more info) TLS 1.2 : 0xc014

    Clear cache, run scan again:
    (n.b. there have been *no* changes to the server/network in the interim)

    POODLE (SSLv3) No, SSL 3 not supported (more info)
    POODLE (TLS) No (more info)
    Zombie POODLE Unknown (more info)
    GOLDENDOODLE Unknown (more info)
    OpenSSL 0-Length Unknown (more info)
    Sleeping POODLE Unknown (more info)

    The server is running Windows Server 2012 R2; there are no load balancers in front of it. Other than the Zombie POODLE issue, it would score an A+ thanks to the IISCrypto tool + HSTS headers. The inconsistency of A+/F grades is rather frustrating :-)

    To my knowledge the vulnerability is known to affect Citrix NetScaler & F5 appliances, not MS Windows Server 2012 R2, so it’s a mystery why it’s being reported. Or SChannel on WS2012R2 vulnerable?

    I’m happy to share the hostname with someone at Qualys via private message, if it would help diagnose any issues with the test.

  19. When I use the same PK12 certificate to sign two sites and test with your sites one returns with a ‘A’ rating whilst the other with an ‘F’.
    The vulnarability shown is ‘OpenSSL 0-Length’

    However when I look at the Cipher Suite section I can see both sites have the CBC ciphers. The only difference that I see is that

    1. Site ‘A’ has four stong Ciphers listed (TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 , TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256) with the rest of the Ciphers listed as weak (13 for TLS 1.2)
    2. Site ‘B’ has only has two stong Ciphers listed (TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) with the rest of the Ciphers listed as weak (6 for TLS 1.2)

    Why excatly does Site ‘A’ pass on ‘OpenSSL 0-Length’ and site ‘B’ fail on ‘OpenSSL 0-Length’ (when both have CBC suites)?

Leave a Reply