Zombie POODLE and GOLDENDOODLE Vulnerabilities
Last updated on: December 23, 2022
Table of Contents
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
- Zombie POODLE
- GOLDENDOODLE
- 0-Length OpenSSL
- Black Hat presentation by researcher
- TLS CBC Padding Oracles in 2019
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.
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
Thanks. Missed it first pass. Must have been the smaller heading font and lack of sleep/coffee.
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.
“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?
Yes. In next release we are going to make Client side CBC as Orange(WEAK).
Regards,
Yash K.S
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
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.)
So, would I lose score if my server isn’t vulnerable to these attacks, but CBC ciphers will stay enabled?
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
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.
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
What is the meaning of “Unknown (more info)” in the result of ssllabs?
Regards
Frank
Hi Frank,
Unknown is the default value when the test starts and it is equivalent to Failed
Regards,
Nauman Shah
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
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.
Hi Max,
SSL Labs now supports labeling cipher suite as insecure/weak in the API
https://community.qualys.com/message/46504-re-get-ciphers-weak-or-strong-status-via-ssl-labs-api#comment-46909
Regards,
Nauman Shah
Hi Nauman,
cool stuff, it helps us a lot. Thank’s for integrating that feature!
Best
-Max
Hello,
correct me if I’m wrong but the only way to get IE11 on Windows 7 is to use GCM instead of CBC is to use ECC certificates but most of the time they are based on RSA?
https://www.ssllabs.com/ssltest/viewClient.html?name=IE&version=11&platform=Win%207&key=36
Windows 7 doesn’t support GCM ciphers by design. You can check the supported ciphers by different Microsoft OS on Microsoft website.
Microsoft security advisory 3042058 added GCM support to Windows 7
https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2015/3042058
Cipher Suites Added by the Update
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
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
Hi Matt,
Since you’ve confirmed that you’re using Netscaler ADC. I would request you to please go through this citrix advisory – https://support.citrix.com/article/CTX240139
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
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
Time to put an nginx server infront!
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
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
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
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?
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
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
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?
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.
Hello Steven,
Thank you for bringing this issue to our notice.
Please share the domain name with me on https://community.qualys.com/people/nshah as a direct message for us to investigate the issue.
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)?
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
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
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
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
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?
Hi Craig,
Thank you for your analysis of the issue it will be of great help to us. Adding to it CT does not have impact on these vulnerabilities so could you please share the domain names for us to assess/identify the issue.
You can share the domain name here or PM in person on this ID https://discussions.qualys.com/people/nshah
Regards,
Nauman Shah
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
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
I’m having consistent false-positive detentions of Zombie Poodle and OpenSSL 0-Length on fully patched Windows 2016 IIS servers.
I sent you a DM.
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.
Is there any update on this? We are experiencing the same.
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?
David,
Can you send(Private message) me URL which you are seeing False Positive?
Regards,
Yash K.S
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?
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
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?
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
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
Hi Mark,
Please share both the domain name with me on https://community.qualys.com/people/nshah as a direct message for us to investigate the issue.
Regards,
Nauman Shah
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.
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.
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?
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
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!