POODLE: SSLv3 vulnerability (CVE-2014-3566)
Red Hat Product Security has been made aware of a vulnerability in the SSLv3 protocol, which has been assigned CVE-2014-3566 and commonly referred to as 'POODLE'. All implementations of SSLv3 are affected.
Background Information
POODLE stands for Padding Oracle On Downgraded Legacy Encryption. This vulnerability allows a man-in-the-middle attacker to decrypt ciphertext using a padding oracle side-channel attack. More details are available in the upstream OpenSSL advisory.
POODLE affects older standards of encryption, specifically Secure Socket Layer (SSL) version 3. It does not affect the newer encryption mechanism known as Transport Layer Security (TLS).
Impact
Avoiding Man-In-The-Middle Attacks
Exploiting this vulnerability is not easily accomplished. Man-in-the-middle attacks require large amounts of time and resources. While likelihood is low, Red Hat recommends implementing only TLS to avoid flaws in SSL.
Avoiding a Fallback Attack
Several vendors have provided patches to cryptographic libraries introducing a TLS Fallback Signaling Cipher Suite Value (TLS_FALLBACK_SCSV). This fallback mechanism allows clients to indicate to a server that they support newer SSL/TLS versions than those initially proposed. In the event of suspicious behavior where a client attempts to fallback to an older version when newer versions are supported, the server will abort the connection.
Currently, only HTTPs clients perform out-of-band protocol fallback.
Products that Red Hat support currently vulnerable from a client side perspective are:
- Firefox
- Chromium
- Curl command line tool and libraries
Currently, Google's Chromium is the only web based browser supported by Red Hat that will handle this functionality client side.
To avoid the fallback attack, supported browsers (only Chromium at this time) must interact with a server supporting TLS_FALLBACK_SCSV negotiation
The server side also needs to be patched to support SCSV extension, and does not need a rebuild with the patched crypto library. Again, due to current lack of support in most common web browsers, any changes server side will only be relevant when client based browsers support the more secure measures.
To learn more about the patched crypto libraries review RHSA-2014:1652-1 and RHSA-2014:1653-1
For non HTTPs clients:
Disabling SSLv3 in favor of at least a TLS connection is recommended. However in disabling SSL it is important to understand that certain applications that do not support TLS could default to plain-text transmission which would be worse from a security perspective than the vulnerable SSL protocol. Before disabling SSL on services, please carefully consider these measures.
Determining Vulnerability
Red Hat Support Subscribers
As a Red Hat customer the easiest way to check vulnerability and confirm remediation is the Red Hat Access Lab: SSLv3 (POODLE) Detector
Non Subscribers
If you are not a subscriber, the script attached to this article (poodle.sh) can be run against a server to check whether it has SSLv3 enabled.
NOTE: This script takes the hostname of the server to check as the first argument and an optional port as the second. By default it will check the local system and port 443.
Resolution
The following guides have been established to help disable SSLv3 for affected products. Red Hat is continuously working at this time to provide additional use cases and guides to disable SSLv3. Note that if you use a third-party service to terminate SSL/TLS connections, then SSLv3 needs to be disabled by the service. Changes on your systems are not necessary in this case.
| Product | Affected Component(s) |
|---|---|
| Red Hat Enterprise Linux | Tomcat, Firefox/Chromium, httpd, vsftpd, Dovecot/Postfix, sendmail, CUPS, other components |
| JBoss Enterprise Middleware | Tomcat/JBoss Web, httpd, EJB (EAP 5), EJB (EAP 6), JMS (EAP 5), Camel, Jetty, Karaf, Fuse, A-MQ |
| Red Hat Satellite | Satellite Configuration |
| Red Hat Certificate System | Tomcat |
| Inktank Ceph Enterprise | httpd |
| Red Hat Enterprise OpenShift | OpenShift Configuration , RHC client tools |
| Red Hat Enterprise Linux OpenStack Platform | httpd |
| Red Hat CloudForms | httpd |
| Red Hat Directory Server | Directory Server Configuration |
| Red Hat Enterprise Virtualization | RHEV-M |
| Red Hat JBoss Enterprise Application Platform | EJB 5, EJB 6, JMS 5 |
| Red Hat Storage Console | httpd |
| Red Hat Update Infrastructure | pulp, httpd |
For More Information
If you have questions or concerns, please contact Red Hat Technical Support
88 Comments
Is there a fix available also confirm how to identify the affected nodes and to patch?
Patches are not available yet, we are working on them as a high priority. In the meantime, please manually disable SSLv3. To determine whether a system is affected, follow the instructions in the "Diagnostic Steps" section of this article.
just disable SSLv3 in the HTTPD config:
SSLProtocol All -SSLv2 -SSLv3
job done
manually we need to downgrade the verison SSLv2 ? any other suggestion ?
Please, do not downgrade to SSLv2. Both SSLv2 and SSLv3 are considered insecure. Instead, disable SSLv3 (or, if you do use SSLv2, disable also SSLv2) in all products/components you use. Once patches are available for this issue, install those (patches are being worked on, see above).
so to calculate the exposure and risk to our environment running RHEL, would it be safe to say only of httpd, firefox/Chromium are used, it is a risk, otherwise other packages that use OpenSSL e.g Openssh usage of libcrypto for example is not an issue?
Please, refer to the table at the top of this article for a list of affected components (i.e. not only httpd and Firefox/Chromium are affected).
The libcrypto library used by OpenSSH contains some routines needed by SSL/TLS but is not affected by this vulnerability. Note that you can also refer to the 'Securing SSH' chapter of the Red Hat Enterprise Linux 7 Security Guide for suggestions on how to improve SSH security.
postfix and dovecote should also be affected and are not shown in the list.
postfix is fixed by adding "smtpd_tls_mandatory_protocols=TLSv1".
Dovecote is not fixable with a config file change in RHEL5 + 6. see BZ 1153027 and BZ 1153041.
The team is working on documenting everything AFAIK, but for now, the priority is on http related packages since there is a know attack for that, and while SSL v3 would also be insecure for others protocols, it may not be exploitable in practice.
How do you intend to mitigate this issue on RHEL5 and earlier? These systems ship with old versions of openssl (e.g., 0.9.8e for RHEL5) that ONLY support SSLv2 and SSLv3.
Are you going to backport TLS support into these old openssl versions, or are you going to update the openssl packages on these systems to 1.0.1e (the same version that RHEL6 and RHEL7 use)?
Either way, I don't envy you for this task: backporting TLS support to 0.9.8e would be horrific, but rebasing to openssl 1.0.1e would also require rebasing every single supported package that links against openssl. And you'd still have to ship the older shared libraries in a compatibility package (e.g., for RHEL5, an openssl098 package that contains libcrypto.so.6) for the older systems anyway, so that third-party applications linked against the now-outdated libcrypto libraries don't block the updates.
Hi,
my RHEL5.11 system supports TLSv1:
$ openssl s_client -tls1 -connect server-that-does-not-support-sslv3
$ rpm -q openssl
openssl-0.9.8e-27.el5_10.4.x86_64
But only tlsv1.0 is supported, not TLSv1.1 or 1.2.
Sorry; you're correct. I was thinking of the results when removing the SSLv3 ciphers from the cipher suite list. Doing so leaves only TLSv1.2 ciphers, which openssl 0.9.8e doesn't support.
As long as the SSLv2 and SSLv3 protocol engines are disabled, it should be safe to leave SSLv3 ciphers in the cipher suite list, as POODLE is an attack on the SSLv3 protocol, not the ciphers.
Is OpenSSL affected .. it is not clear from the Table .. when i clik on the OpenSSL link on the Affected components it gave me this error
Access denied
You do not have permission to access the page you requested. If this is knowledge content, it may be unpublished or retired. Documents may be retired when they are outdated, duplicated, or no longer necessary. Please try searching the Customer Portal for the most current, published information.
The problem is independent of the library, it is on the protocol itself ( version 3 of SSL ), not the implementation ( openssl, gnutls ). So yes, all libraries are affected, but the only fix is to disable the protocol usage.
How do you disable SSL3?
This is covered in the "Resolution" section of this article and is specific per service and application.
Never mind, I found it.
What about RHDS? Is that product affected?
Easy way out would be to do the following and then restart dirsrv:
dn: cn=encryption,cn=config
changetype: modify
replace: nsSSL3
nsSSL3: off
If it use ssl v3, it would be problematic in theory.
Now, the POODLE attack requires a attacker to be able to intercept trafic ( something much harder to do for ldap, as that's usually internal to a company lan ), a client that would downgrade the connexion from tls to ssl v3, ( which is maybe not the case for ldap clients ). It also requires to be able to inject data in the connexion to make the client retry the request, and the POODLE attack therefor work only on browser due to javascript support. While I am sure someone can maybe find a creative way to exploit it later, there is for now no known attack, so that's as critical to fix as https connexions.
When I run the above script I get "SSL disabled or other error" ... Does it mean that there is no service running which can cause this vulnerability ?
I believe that means you're safe. if you get "SSL 3.0 enabled", that's an issue.
Confirm you are pointing it to your SSL port. Sometimes its 8443 instead but it could be any port.
We did disable SSLv3 from "SSLProtocol" line. But, do we need to change "SSLCipherSuite" as well? By the way, what is the recommended value for "SSLCipherSuite" in general?
You don't need to change the 'SSLCipherSuite' directive because of this specific vulnerability, but you should ensure the settings are appropriate for your use case/environment. Please, see chapter 'Hardening TLS Configuration' in the Red Hat Enterprise Linux Security Guide for recommendations on how to set up SSL/TLS, choice of cipher suites, etc.
One of the engineers here, ran the script on a 5.x box, and it said "SSL disabled or other error". He then took the >/dev/null out and received this:
jarrellg@carpsyinfint01 ~ $ ./x.sh
./x.sh: line 2: timeout: command not found
SSL disabled or other error
jarrellg@carpsyinfint01 ~ $
x.sh
!/bin/bash
ret=$(echo Q | timeout 5 openssl s_client -connect "${1-
hostname}:${2-443}" -ssl2 )if echo "${ret}" | grep -q 'Protocol.SSLv3'; then
if echo "${ret}" | grep -q 'Cipher.0000'; then
echo "SSL 3.0 disabled"
else
echo "SSL 3.0 enabled"
fi
else
echo "SSL disabled or other error"
fi
We did some digging and found that timeout is in /usr/share/doc/bash-3.2/scripts
Did a chmod on the file to execute and the script worked fine.
15094:error:1407F0E5:SSL routines:SSL2_WRITE:ssl handshake failure:s2_pkt.c:427:
SSL disabled or other error
Dovecot in RHEL5 and RHEL6 doesn't know the option ssl_protocols.
How can I disable SSLv3 then?
You have to fix it in code. See BZ#1153027 and BZ#1153041.
This article states that TLS stands for 'Transport Socket Layer', it should say 'Transport Layer Security'.
Thanks for noting this error, it has now been corrected.
openssl s_client -connect "${1-
hostname}:${2-443}" -ssl3${2-443} <Does it mean we check the vulnerability on ports from 2 to 443 ? what if I am running ssl'ed service or > 443 ? Does this script identify the vulnerability my ssl'ed service is running on say 8443 ?
Test script can be run with 0 to 2 arguments:
- first argument is host name of a server to test - default value is the name of system you run the script on
- second argument is port the service runs on - default value is 443/https
${2-443} is shell syntax that causes script to use value of 443 as port number if script was run with less than 2 arguments.
Tomas, thanks for educating me on the shell script thing, really appreciate it.
I know at application layer run the script and if "SSL 3.0 enabled" shows up disable in the corresponding application using the method(s) mentioned in Resolution
Can you advice if there is anything that we need to do at the OS layer ?
The verification script for subscribers (not the one in this post) doesnt work:
$ echo QUIT | openssl s_client -connect redhat.com:443 -tlsextdebug -ssl3 2>&1 | grep -q SSLv3 && echo UNSAFE || echo SAFE
SAFE
$ bash poodle.sh redhat.com
VULNERABLE! SSLv3 detected
Hi,
Tested and found our server is sslv3 enabled, have disabled sslv3 for apache in /etc/httpd/conf.d/ssl.conf.restarted apache.
after that when is tested with the diagnostic script, i got the below output, which means sslv3 is completely disabled, please advise.
[root@njdevftp01 tmp]# sh poodle.sh
28363:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1092:SSL alert number 40
28363:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:536:
SSL disabled or other error
"SSL disabled or other error" caused on RHEL 5 due to missing "timeout" command:
Don't use a script which isn't accessible/executable by default on RHEL 5 systems. Better write "clean" scripts.
Workaround:
Use ulimit.
$ head -3 poodle-detect.sh
!/bin/bash
ulimit -t 5
ret=$(echo Q | openssl s_client -connect "${1-
hostname}:${2-443}" -ssl3 2> /dev/null)Test on RHEL 5:
$ ./poodle-detect.sh 127.0.0.1 443
SSL 3.0 enabled
$ ./poodle-detect.sh 127.0.0.1 444
SSL disabled or other error
Any news about the patches for this?
Can you post how to check the logs to detect if a system was compromised this way?
And a way to check in existing logs whether or not clients use any of the vulnerable encryption mechanisms?
Regards
Bram
Hello Bram,
Some information about this is available under "Is it possible to monitor for exploit attempts?" on the Security Blog: https://securityblog.redhat.com/2014/10/15/poodle-a-ssl3-vulnerability-cve-2014-3566/
Hi Martin,
Thanks I have read that article as well but I am looking for more specific instructions.
So far I've checked the ssl_request logs of my apache servers looking for "SSLv3" in the "%{SSL_PROTOCOL}" directive.
Is this check sufficient?
Is there a similar check possible for vsftpd?
Regards
Bram
Hello Bram, sorry for the late reply. Yes, checking your SSL logs for your Apache servers is a good start. You can also check access logs for signs of an unusual number of requests from a single host in a short amount of time. The attack requires at least 256 connections attempts to be made using SSL 3.0.
As far as vsftpd goes, you must have "debug_ssl=YES" configured in your vsftpd.conf file. You can then examine connections that were made to your server and see which protocol was used. Again your tell-tale would be unusual amount of requests from a single host, or similar odd activity.
I hope this help.
Martin
Hello,
I got the following output from script.
=================================
[root@Hostname ~]# if echo "${ret}" | grep -q 'Protocol.*SSLv3'; then
SSL disabled or other error
Does it mean that I am safe ??
Hello, we just updated the script in this article. Please see the new version attached. It should give you a definitive answer ("vulnerable" vs "not vulnerable") when testing your server.
Will an update be made so the poodle.sh script works on RHEL5?
Hi Bernie,
The poodle.sh script now checks for the timeout utility (part of coreutils in RHEL 6 and up), which is what prevented it from working on RHEL 5.
I ran the "offline detection tool" on one of my RHEL 6 servers, and I received the following message:
"error: Unable to connect to host :443"."
I'm assuming this is not a problem, yes?
Hi Phil, this means that the host that you're trying to connect is not available on port 443 or the host address is not correct.
An enhanced version of the script is described at
http://www.tuxad.de/blog/archives/2014/10/16/poodle_detect_script/index.html
It doesn't use "timeout" and distinguishes between "error" and "sslv3 disabled".
Hi
Prepared by Red Hat script check only port 443.
If someone want check other ports, can use my modification.
Script checks all port in state LISTEN on host.
!/bin/bash
HOSTNAME=
hostname -f | cut -d'.' -f1FILE=/tmp/${HOSTNAME}_poodle.log
A=0
if [ -f ${FILE} ]; then
rm -rf ${FILE}
fi
for i in $(/usr/sbin/ss -n -a | awk '{print $4}' | cut -d':' -f2 | sort| uniq)
do
ret=$(echo Q | timeout 5 openssl s_client -connect "${1-
hostname -f}:${2-${i}}" -ssl3 2> /dev/null)if echo "${ret}" | grep -q 'Protocol.*SSLv3'; then
if echo "${ret}" | grep -q 'Cipher.*0000'; then
:
else
fi
else
:
fi
done
if [ "${A}" -ne 0 ]; then
echo "SSL 3.0 enabled"
exit 0
else
echo "SSL 3.0 disabled"
exit 1
fi
Update to your "ss" instruction - Filter out extraneous text with grep.
Also to note: older versions of RHEL may not even have "ss" installed.
RH script DOES offering checks of all ports.
It's the sceond arg. RTFM (man bash)!
(And your script will also fail on RHEL 5 like original RH script does.)
Can I remove the vulnerability by applying this version? <openssl-1.0.1e-30.el6_6.2.x86_64 2014-10-15>
https://rhn.redhat.com/rhn/software/packages/details/Overview.do?pid=1011841
Just take a look into the changelog.
There's a notice of 2014-10-15 about CVE-2014-3566.
:-)
CVE-2014-3566 issue is an SSL 3.0 protocol flaw and is not expected to get fixed. The openssl updates released via RHSA-2014:1652 and RHSA-2014:1653 add a partial mitigation, which aims to protect applications that do unsafe re-connect TLS version fallback (most notably web browsers).
The only protection against the issue is to avoid use of SSL 3.0. If both client and server support at least TLS 1.0, they can not be forced to negotiate SSL 3.0 if they don't do the unsafe fallback mentioned above. You can disable SSL 3.0 in various services, which will prevent SSL 3.0-only clients from being able to connect to them.
Example of checking multiple ports:
$ echo 443 8443|xargs -n 1 ./poodle-detect.sh 127.0.0.1
SSL 3.0 enabled
unknown error
According to The Register (http://www.theregister.co.uk/2014/10/15/openssl_ddos_vulns/), the upstream packages have POODLE fixed in OpenSSL versions 0.9.8zc, 1.0.0o, and 1.0.1j.
If RedHat can't just replace 0.9.8e with 0.9.8zc for some reason, they should at least be able to back-port the changes. Given that there are now fixes, I think it's just a matter of time (hopefully not a lot of time) for RedHat to port the patches to RHEL 5, 6 and 7.
Update for Red Hat Enterprise Linux 5 was already released, see RHSA-2014:1653. It adds TLS_FALLBACK_SCSV support, a partial mitigation for the POODLE attack (can protect applications that use unsafe re-connect protocol version fallback). Other fixes applied upstream in 0.9.8zc are not applicable to Red Hat Enterprise Linux 5 0.9.8e packages.
Red Hat Enterprise Linux 6 and 7 erratum is RHSA-2014:1652. It adds TLS_FALLBACK_SCSV support, and fixes CVE-2014-3513 and CVE-2014-3567 memory leaks.
Thanks Tomas. I've already removed SSLv3 from httpd. On a fully patched server, how do I verify that it supports TLS_FALLBACK_SCSV correctly?
If you disabled SSLv3, TLS_FALLBACK_SCSV becomes irrelevant in the context of the Poodle issue, as downgrade to SSLv3 is no longer possible.
The server needs to enable at least two TLS/SSL versions to be able to test TLS_FALLBACK_SCSV with it. If TLS_FALLBACK_SCSV is sent when connecting using TLS/SSL version that is not the highest version server supports, server should reject connection.
The openssl's s_client tool allows you to sent TLS_FALLBACK_SCSV easily. E.g. you can try:
SSLv3 connections is established fine. However, if this is used:
Connection is rejected with
tlsv1 alert inappropriate fallbackerror.As google servers support TLS versions up to 1.2, you should see similar error when connecting using
-tls1or-tls1_1with-fallback_scsv.Thanks Tomas. Exactly what I needed. :)
Why aren't subscribers getting email info on the updated packages now they're available?
In order to get errata email notifications, you must have them enabled here https://www.redhat.com/wapps/ugc/protected/notif.html Please note these are controlled independently for systems registered via Red Hat Network Classic (RHN) and Red Hat Subscription Management (RHSM). A link to control these settings for RHN is on the page above as well.
If you had the proper notifications enabled, but did not get emails for these errata, please open a support case.
Patech Support, I do not see that the patches are available yet from Red Hat as I type this, see https://access.redhat.com/security/cve/CVE-2014-3566, do you have a link for these patches from Red Hat?
(note I'm typing this 7:20AM Eastern Time Oct 17th, 2014)
Hi
RHEL5 openssl patch seems to be incomplete.
Client request (through openssl lib) for TLSv1 will still using SSLv3?
Connection to that host can not be established with older Red Hat Enterprise Linux 5 openssl packages. A quick testing suggests that the site only allows SSL connections using ECDH cipher suites, or one of the AES-GCM ciphers (TLS 1.2 only). Neither of those is supported by Red Hat Enterprise Linux 5 openssl packages.
You are right Tomas,
real case is remote host provide only ciphers which RHEL5 openssl (0.9.8e-31.el5_11) not support.
Misleading was the inaccurate openssl error string "sslv3 alert handshake failure" which appears for SSLv3 and TLSv1 handshake errors.
Oh my, this circumstance will create many cases in future. :(
How to remediate this issue in Fuse ESB 6.0 and 6.1 server ??
Does anyone know when patches will be available for POODLE?
Hello:
We have a couple of servers that are not running Apache (httpd) and are not identified as any of the other Products noted above, ex. Directory Server, Certificate, etc.; however, the POODLE script still identifies it as being VULNERABLE.
UPDATED: The two servers are running RHEL 5.6 or 5.7 (Taconga).
Any ideas of what else to check for?
Thank you in advance for your assistance.
Figured it out. It took some digging.
UPDATE: One of the servers is a Helix Real Media Streaming server. The other is a web log server.
I used the the new script and got the following output, I am running RHEL 5.4 Enterprise edition with Oracle EBS
[root@HOSTNAME install]# perl poodle.sh
127.0.0.1:443 - Not vulnerable. Failed to establish SSL connection.
Does it mean I am safe ??
That script is ... lacking. All it does (when not given any arguments) is try to connect to the local host that it is being run on using SSLv3 on TPC port 443. What it told you was that no service responded to HTTPS on 127.0.0.1:443. Which could mean that Apache is not listening on the localhost address. You should try supplying arguments to the script like:
Also, it is a BASH script, not a Perl script. You should either chmod it +x or invoke it with bash, not Perl.
The poodle.sh script would/should have the following usage syntax:
Where both arguments are optional, and their values are any valid host name, IP address, and TCP port where a HTTPS service is listening. The default values used are IP address 127.0.0.1 and port number 443.
This 'fix' is breaking all my repos that require HTTPS but are rejecting SSLv3. How do you force Yum to connect to a HTTPS repo using TLS? EPEL, for instance, is broken for me right now.
I did a quick testing with Red Hat Enterprise Linux 5 and 6. In both versions, yum was able to communicate with TLS 1.0 only https repository. You may need to open bug / support case with more details.
Did you actually test using yum?
If i use openssl it works just fine:
However, if I watch yum using tcpdump I see the TLS handshake complete Client Hello, Server Hello, Certificate, Server Key Exchange, and Server Hello Done. The server negotigates the same cipher suite as openssl: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033). But the client immediately follows up with an ack and a fin/ack TCP request. The Client Key Exchange never takes place, and no Content Type of Alert are sent.
I will open a ticket if you can validate that its an isolated issue. I am on 6.3, if that matters.
Testing was with yum, with recent updates installed.
So, this implies that you are only going to test this on the latest release of RHEL6? There is a problem with RHEL 6.3, yum-3.2.29-30.el6.noarch, and yum repos disabling SSLv3, but I guess i will have to open a support ticket or bug report.
HI, Is there any fix available other then disabling SSL3 ? Can i upgrade openssl to latest patch that is available from RedHat?
hi Sunny -- no, you must disable SSL3. The vulnerability is with the protocol itself, not any specific implementation of it.
Hi Red Hat, note that SSLv3 (POODLE) Detector has been down all week, even for those of us with subscriptions.
Hi! I just tested all the functionality in our SSLv3 (POODLE) Detector and it works as expected. Could you please provide any details on what the issue is on your end?
Hello:
We identified that an Apache webserver was vulnerable using the Red Hat-provided scripts.
We have turned off SSL3 in the httpd (Apache) .CONF file and restarted HTTPD, then retested with the check for vulnerability scripts, and all reported no longer vulnerable;
however, when I provided a website URL from a website that resides on that Apache server into the test here:
https://access.redhat.com/labs/poodle/
the result came back as vulnerable.
I turned off SSL3 in the website's secure.<website's name>.conf file, restarted Apache, and then checked the website again, and this time the website was identified as "not vulnerable".
My questions are:
1). Is this a false-positive reply against the website since HTTPD (Apache) has already been updated to not use (turned off) SSL3 on the host server?
2). Do I need to turn off SSL3 in all the respective websites' secure.conf files and restart Apache?
Hi Phil, it's not obvious to me from your comment whether you're running a single Apache web server with your multiple sites configured as VirtualHosts or multiple instances of Apache running each website. For the former, amending the main config file and restarting should be enough. For the latter, you must amend all config files and restart all instances of Apache.
One RHEL server, running one instance of Apache, and have several secured websites, each has their own secure .CONF file, and in each secure .CONF file defines:
:443>
We have edited "/etc/httpd/conf.d/ssl.conf" by changing the SSLProtocol to
"SSLProtocol all -SSLv2 -SSLv3"
and then restarted HTTPD.
So, it would seem that this is resolved, but, if I haven't modified the secure .CONF file for one of the websites on that server, and then you insert
https://
into the "Online server tester" from
https://access.redhat.com/labs/poodle/
I then get a "Status: Vulnerable"
This would seem to be a false-positive then, correct?
Are you supplying the Host and Port arguments to the shell script? The script expects ARG1 to be the hostname and ARG2 to be the port. If you do not supply the arguments, then 127.0.0.1:443 is used. Whatever default vhost listens on Apache will be the one that gets tested. It will not test all vhosts, and it will not test any per-directory SSLCipherSuite configurations. The script really could have been written better.
Read my response, above, please.
I see there is no fix for OpenLDAP currently. There's only an article which acknowledges this and then goes on to say you can mitigate this vulnerability by wrapping slapd around stunnel. Do you plan to release comprehensive documentation on how to do this? Is a patch planned for OpenLDAP? Is configuring every LDAP client to use stunnel really an efficient means to disable SSLv3?
Hello Mike
the docs team is currently reviewing all guides to see which sections are impacted by this issue. We will work with subject matter experts to add warnings and, where possible, instructions for mitigating or preventative measures.
Pages