Zombie POODLE and GOLDENDOODLE Vulnerabilities

Yash Sannegowda

Last updated on: December 23, 2022

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.

Show Comments (70)

Comments

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

  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

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

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

    2. 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?

    1. 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.)

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

      1. 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?

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

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

  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

    1. You’ve misunderstood the API values of futureGrade and hasWarnings.

      SSL Labs API no longer supports futureGrade as it was only introduced for these changes (https://blog.qualys.com/ssllabs/2017/01/18/ssl-labs-grading-changes-january-2017). There was a GitHub issue asking for the same after it was removed https://github.com/ssllabs/ssllabs-scan/issues/564

      SSL Labs has a policy of warning a users/admin 30 days in advance before applying any grade change. This warning summary does not apply for grade change as it is just an informative message. You can simply use the zombiePoodle value from the API directly.

      Labeling ciphers as WEAK, we don’t have it in API yet. We will be adding it in the upcoming release.

    1. Windows 7 doesn’t support GCM ciphers by design. You can check the supported ciphers by different Microsoft OS on Microsoft website.

  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?

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

    2. 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?

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

    1. 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)?

  20. We are running Oracle Web Server on TLS1.2 with following ciphers
    SSLCipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

    but when we test Websote URl on https://www.ssllabs.com/ssltest/ it show, we still using CBC Cipher , Could you please tell why ?

    Cipher Suites
    # TLS 1.2 (server has no preference)
    TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c) WEAK 128
    TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) WEAK 128
    TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d) WEAK 256

  21. The Zombie Poodle vulnerability scan is a bit confusing
    We are getting the below from the scans. The first two are positive but the rest are failing on TLS1.2 . We only have TLS1.2 enforced. So should we disable all CBC ciphers?

    TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH secp256r1 (eq. 3072 bits RSA) FS 128
    TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH secp256r1 (eq. 3072 bits RSA) FS 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_CBC_SHA384 (0xc028) 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_SHA (0xc014) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK 256

    1. Hi Naveen,

      Good to see that you’re using TLS 1.2 only in your protocol configuration.

      Here Zombie Poodle vulnerability is an implementation bug that leverages the CBC Cipher mode. If SSL Labs says that your server is vulnerable to Zombie POODLE then you’ve two solutions in place 1. Check with your vendor for a patch/update 2. Disable the CBC cipher mode.
      I would suggest you look for a patch/update rather than disabling the CBC based cipher suites

      Regards,
      Nauman Shah

  22. Hi,
    I have two servers with stunnel for SSL termination. Both Win2016 and both with stunnel 5.55 and both with same ciphers configured. One gets an F and the other gets an A. I think they should both get an F. Is there any way to get an explanation for these results?
    Thanks
    Craig

    1. Update to prior post. I did identify one discrepency but it relates to the SSL certificate in place.
      Both are valid certificates with full chain issued by DigiCert. However, the older certificate does not have Certificate Transparency.

      On the same server with nothing else changing, if i put the certificate in place with does have Certificate Transparency I get an F. If i put the older certificate in place then i get an A with nothing else changing.

      Why would adding Certificate Tranparency weaken the system? This seems like it might be a bug in the scan results?

  23. Hello,

    Well, I don’t understand the rating. I’ve tested two URLs/servers supporting exactly the same protocols (TLS 1.0, 1.1 and 1.2) and cipher suites (see below). For one I get F, due to an exploitable Zombie Poodle, and for the other I get A.
    Can someone explain?
    Hereunder are the cipher suites:
    # TLS 1.2 (suites in server-preferred order)
    TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) ECDH secp256r1 (eq. 3072 bits RSA) FS 128
    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK 128
    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK 256
    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK 128
    # TLS 1.1 (suites in server-preferred order)
    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK 256
    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK 128
    # TLS 1.0 (suites in server-preferred order)
    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK 256
    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK

  24. Hi,

    our site may be affected by this vulnerability.
    But we get the detection of this vulnerability only from every 5-15 times we scan our site.
    Are there any potential false positive factors that could lead in an wrong result?

    Regards

    1. With our recent investigation, it was observed that SSL Labs is giving false-positive results for the Zombie Poodle, GOLDENDOODLE, Zero Length Padding Oracle and Sleeping Poodle vulnerability when the server is using IIS. We are yet to find the root cause of this issue and we are working on it.

      1. Is there any plan about when SSL Labs can fix false-positive for the Zombie Poodle, GOLDENDOODLE, Zero Length Padding Oracle and Sleeping Poodle vulnerabilities?

  25. The author of Zombie Poodle (Craig from Tripwire) says “Zombie POODLE generically refers to the exploitation of a wide-range of implementation errors which create this valid MAC/invalid pad oracle.”

    So if Zombie Poodle means every way a padding oracle could materialize, how are you possibly testing for this?

    1. Hello Jack,

      Like you’ve already mentioned about implementation errors and valid MAC/Invalid pad oracle. We send a valid MAC/Invalid pad based packet/request which should ideally be rejected by server by responding with a bad mac record i.e failure at ssl level but if the server sends a valid response i.e the server accepted the malformed request at ssl level. By this manner we figure out the server is vulnerable.

      Regards,
      Nauman Shah

      1. Thanks Nauman,

        In the implementation of your test, is a valid response any response except SSL alert 20 (bad record MAC) or is it a very specific type of response?

        1. We send a malformed request, here if the server responds to this malformed request with valid response i.e complete handshake with no alerts then we say that such a server is vulnerable these are confirm cases of vulnerable servers. If the server responds to the malformed request with a “bad MAC record error” i.e handshake alert then we say that such a servers are not vulnerable.

          For more information please refer researchers tool – https://github.com/Tripwire/padcheck

          Regards,
          Nauman Shah

  26. Hi,

    I’m getting an F result for one site that appears to have the same configuration as another that gets an A+. I can’t see the difference in the results other than one report highlights Zombie Poodle vulnerability due to CBC ciphers and the other seems to ignore this. Is this a bug or am I missing something?

    Regards,
    Mark Shackley

  27. I have a server with TLS 1.2 + 1.3 and it gets A+.
    However when I disable TLS 1.2 I just get A.
    I suppose there is an issue there, I would have expected to still get A+.
    Can you have a look?
    Thanks.

  28. Our MS 2016 servers are detected as vulnerable recently and below is the solution provided by Qualys team.
    ====================
    Please refer to official github page TLS Padding Oracles for affected products and patch links.
    Patch:
    Following are links for downloading patches to fix the vulnerabilities:
    OpenSSL Security Advisory: OpenSSL
    ====================

    This vulnerability was initially reported in 2019 and our servers were not vulnerable until Jan’2022.
    It seems to be false positive vulnerability. Would like to know if there is any solution for this vulnerability if our servers are really vulnerable. We are not using any of the products which are listed in “who is effected” github link. kindly note that some of our servers are not even running IIS.

  29. Why does main Qualsys report give a server with weak TLS 1.2 CBC ciphers an A grade with no POODLE / GOLDENDOODLE vulnerabilities, while this article (accessible from “more info” link next to the weak ciphers) says they should have an F grade since May 2019?

  30. Hi Yash,

    Please advise how can we fix the Zombie POODLE and GOLDENDOODLE Vulnerabilities in windows server 2016 knowing that only TLS 1.2 is enabled in the system

  31. Hello there! I know this is kinda off topic however I’d figured I’d ask. Would you be interested in exchanging links or maybe guest authoring a blog article or vice-versa? My site addresses a lot of the same topics as yours and I feel we could greatly benefit from each other. If you’re interested feel free to shoot me an e-mail. I look forward to hearing from you! Great blog by the way!