search

ssllabs / ssllabs-scan

A command-line reference-implementation client for SSL Labs APIs, designed for automated and/or bulk testing.
https://www.ssllabs.com/projects/ssllabs-apis/
Apache License 2.0
1.71k stars 243 forks source link

POODLE False positive ? #885

Open jchasles opened 2 years ago

jchasles commented 2 years ago

Hi,

We testing our site with ssllabs and it seems we have false positive with POODLE vulnerability.

In majority of testign we have grade F, and sometimes grade A (without POODLE)

https://www.ssllabs.com/ssltest/analyze.html?d=temppoc.henner.com

???

The POODLE vulnerability are never detected on other site (www.immuniweb.com)

Regards

RobTho commented 2 years ago

Do you have a loadbalancer?

jchasles commented 2 years ago

Hi yes we have a LB A10 Networks to do ssl offloads

Regards

RobTho commented 2 years ago

such issue normally happen when one of x servers behind your LB is not set correctl. So each time you scan this url, your LB may choose the good or the bad server and this will result in this inconsistent behavior.

jchasles commented 2 years ago

No, it's not a LB issue. The SSL offload is made by the LB not by the end server. And for this test, we have only one real server behind the LB.

ethhack commented 1 year ago

Seeing the same issue here.

In our case, NO LB's in play, yet almost every other month, our PCI ASV scan (Sysnet) fails us when it uses Qualys to test for Zombie Poodle. Yet 6 out of 7 times (the 7th time it'll fail), SSLLabs shows us clean, as do ALL NMAP ssl-poodle.nse tests and cipher checks with python. The targets in question are single Cisco VPN servers (again, no LB's in play) which are configured ONLY for High Ciphers. It seems that the same failed tests for Zombie Poodle also error on DROWN (and when one passes, so does the other), and the DROWN test shows connection timeouts:

DROWN

Unable to perform this test due to an internal error. (1) For a better understanding of this test, please read this longer explanation (2) Key usage data kindly provided by the Censys network search engine; original DROWN website here (3) Censys data is only indicative of possible key and certificate reuse; possibly out-of-date and not complete INTERNAL ERROR: connect timed out INTERNAL ERROR: connect timed out

Are you auto-failing Zombie Poodle and / or DROWN because of response differences, simply because you're either dropping connection or not receiving replies fast enough (if network congestion, etc)? If ASV scanners are relying on this scan and are consistently (every couple of months) causing customers to have to rescan to pass PCI compliance, etc, that's a flawed approach, IMHO.

Please advise.