SSLv3 (POODLE) Detector
The SSLv3 Detector allows customers to scan vulnerable systems for CVE-2014-3566 (POODLE).
This tool is intended as a supplement to the help Red Hat customers identify vulnerable systems they manage and validate once they are fixed. To mitigate this vulnerability, SSLv3 should be disabled in all affected systems, as described in Red Hat's documentation POODLE: SSLv3 vulnerability
All implementations of SSLv3 are affected. Red Hat Enterprise Linux and other Red Hat products include libraries which enable the use of SSLv3. This vulnerability does not affect the newer encryption mechansim known as Transport Socket Layer (TLS).
Please only use this to scan servers you have permission to. All scans are logged.
Was this helpful?
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
Comments
Subscriber exclusive content
An active Red Hat subscription is required to participate.
Log InMissing Poodle Detector!
Page not found!
/labs/poodle
Where is poodle detector?
Same here, I was checking my URLs and now the page is not found.
Ok the site is back up. thank you
Please edit your examples comments to reflect correctly which one is vulnerable. The comments should not say they're both "not vulnerable"
Please visit https://access.redhat.com/labs/poodle/ to actually use the app. This is the information page.
I have 3 systems that no matter which correction I make their URL's are still showing as vulnerable. I have 2 servers that are Red Hat 6.5 that have the same configurations as other servers in my farm and when I run the path ______________ or ____________ both are different servers I get a response back that these are vulnerable. My ssl.conf file has SSLProtocol -All +TLSv1 on both servers.
Is there something else I can do or check to make sure I'm protecting my servers?
The third server is an old Plesk server that is running CentOS on the backend. I know that RH doesn't support CentOS, I just wanted to make it aware that CentOS based OS's with Plesk Control Panel is also showing as Vulnerable, all websites I've tested on that server show vulnerable. Even though I've got SSLProtocol All -SSLv2 -SSLv3 in the httpd.conf file.
edit: scrubbed hostnames :-D
Thank you for doing so.
Hi Kelly,
Did you make sure to restart httpd after updating the ssl config? Also make sure there are no additional ssl configuration settings inside any VirtualHost entries.
Yes I did many times, also I ran a grep command to seek out any other SSLProtocol entries. I ran...
$grep -R -i SSLProtocol /etc/httpd/conf* Returned only this...
/etc/httpd/conf.d/ssl.conf:SSLProtocol All -SSLv2 -SSLv3
Everything is the way it's supposed to be however this server is not reporting that the vulnerability is removed.
I've opened a support ticket Case Number : 01264194
I manually tested against the two hostnames you mentioned and they do in fact still support SSLv3. Please follow up with the person in the Support Case, they should be able to do additional diagnostics to determine why your HTTPD server's are still accepting SSLv3 connections.
@Kelly, the "connection" request is showing up with SSLv3 vulnerability - it may be a different completely service answering than what you are editing. Make sure to go to "each interface" by IP address (not DNS name) for each port of interest. (Scripts could point to a different path on startup!) In your case, I would stop the web services you think you've updated, and see if you get the same result. If something still answers on port 443, use "lsof" to identify which process is opening that port.
Also, some of us use high ports for the web traffic, and aren't found on "443", yet are still vulnerable because they are using a load balancer to get to that high port. My classic problem is that the Load Balancer is picking up the queries, and forwarding them to yet another host I haven't updated yet. Follow your traffic all of the way down to each individual server.
Lastly, I would not be surprised to find out some load balancers that offer SSL service offloading have this same failure, so no matter how many web servers you update, it won't ever show up properly. Learn the path of the traffic from start to finish, and see where your failure truly lies. I personally would copy the script to each web server, and use "localhost" or "127.0.0.1" and see if you get the fail message or not.