Poodle SSLv3 vulnerability

DirectAdmin Support

DirectAdmin Support

Administrator
Staff member
Joined
Feb 27, 2003
Messages
8,138
Update Oct 16th:
A version of OpenSSL has been released which adds support for TLS_FALLBACK_SCSV.
Update openssl and restart your services:
Code: 
yum -y update openssl
But we do still recommend disabling SSLv3 anyway.
I've found a few sites that support the proper TLS_FALLBACK_SCSV test, so confirm the SSL ports pass, either by support for TLS_FALLBACK_SCSV, or by disalbing SSLv3.
https://www.ssllabs.com/ssltest/index.html
https://www.tinfoilsecurity.com/poodle

---------------------------

Hello,

As many of you area likely already aware, a new vulnerability was discovered in SSLv3 called "Poodle":
http://googleonlinesecurity.blogspot.com.au/2014/10/this-poodle-bites-exploiting-ssl-30.html

As such we've released a new set of ciphers that we recommend everyone change to use:
http://help.directadmin.com/item.php?id=571

I'm hoping to write a simple script you can download and run to make all of these changes for you, but for now, just make the changes to the mentioned files (if you have those files), and restart your services.

There is more info an discussion in this thread:
http://forum.directadmin.com/showthread.php?t=50099



If you'd like to test your ports, I've written this *very* basic php script that simply checks for SSLv3 (not the TLS_FALLBACK_SCSV change):
http://files1.directadmin.com/services/all/ssl_test.php.txt
I don't recommend making this a public URL as it does run command line functions (delete script when you're done)

Save it to a .php file on your system, and access it through apache.
The function "exec" cannot be in the disable_functions list.
Note, your may see TLSv1 and TLSv1.1 not work be reported as "bad", but that context of "bad" just means some older clients may break.
The main goal is to see SSLv3 disabled, but TLS enabled (preferably inclusive of v1 and 1.1)

John
 
DirectAdmin Support said:
Hello,

As many of you area likely already aware, a new vulnerability was discovered in SSLv3 called "Poodle":
http://googleonlinesecurity.blogspot.com.au/2014/10/this-poodle-bites-exploiting-ssl-30.html

As such we've released a new set of ciphers that we recommend everyone change to use:
http://help.directadmin.com/item.php?id=571

I'm hoping to write a simple script you can download and run to make all of these changes for you, but for now, just make the changes to the mentioned files (if you have those files), and restart your services.

There is more info an discussion in this thread:
http://forum.directadmin.com/showthread.php?t=50099

John
Click to expand...

We made this change to Dovecot and Exim but see issues with many clients:

Dovecot:
TLS handshaking: SSL_accept() failed: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher

I suppose this is because the client is using SSLv3 and not TLS in Outlook/Apple mail, waiting for an answer if changing to TLS fixes the problem.
 
Last edited:
I've done more digging and have updated the guide again:
http://help.directadmin.com/item.php?id=571

For DA, the ciphers only allow for TLSv1.2, so I've updated the binaries themselves to allow TLSv1, TLSv1.1 and TLSv1.2.
Note, even if you've got ssl_ciphers=SSLv3, the new binaries will still only allow TLS 1, 1.1, and 1.2.
They're in the pre-release area if anyone needs them.

Exim required me to actually dig into it's source code to figure out how to use the no_sslv3 option, but figured it out.

So with the new ciphers list, and the pre-release DA binaries, you can disable SSLv3, but still have all 3 TLS types.
If you don't get the new DA binaries, then you'd use the -SSLv3 cipher, which would then give you only TLSv1.2.. which isn't that bad anyway, since most browsers should support it.

John
 
I have a few questions. Will the ciphers in the guide be the new default values on DirectAdmin installs? I need to consider that when deciding if I am going to apply them or not. This is shared hosting servers, so there could be problems for a few clients.

Also there is released a patch from OpenSSL https://www.openssl.org/news/secadv_20141015.txt wich should soon be in RedHat/CentOS, but some say that is not enough so we need to completely disable SSLv3?

Also please note that there is currently report that Firefox current newest version does not not support TLS connections to ports other than 443: http://www.webhostingtalk.com/showpost.php?p=9263694&postcount=43 However I am not sure that is true, and here is user posting he managed to get it to work: http://www.webhostingtalk.com/showpost.php?p=9264590&postcount=59

It is a real consern to completely disable SSLv3 when hosting shared hosting customers. There is many things that can break for customers, for example in email clients of all variants etc.
 
It's there for Debian already.

I had installed it and restarted nginx, and at ssllabs it now says:

"This server supports TLS_FALLBACK_SCSV to prevent protocol downgrade attacks." :)
 
DirectAdmin Support said:
Hello,

I'm hoping to write a simple script you can download and run to make all of these changes for you, but for now, just make the changes to the mentioned files (if you have those files), and restart your services.

John
Click to expand...

... > 90 managed DA servers,..
Need the script.
Too many manual fixes..

-Sup.
 
It's now in CentOS, they did a exception and added it in CentOS 6.5, so we did not have to wait for CentOS 6.6: http://www.mail-archive.com/[email protected]/msg08690.html:

NOTE: This update is released into the CentOS-6.5 tree and has a .el6_5 dist
tag, *NOT* the .el6_6 dist tag that Red Hat used for RHEL in the link above.

This update was built against 'CentOS-6.5 + updates' and that is where it is
intended to be used.

The CentOS team will build and release a openssl-1.0.1e-30.el6_6.2.src.rpm as
a zero day update to CentOS-6.6 when that is released as we are currently
building CentOS-6.6 from the released Red Hat Enterprise Linux sources.

Please also note that even after installing this update, further action is
required to mitigate the POODLE issue on CentOS-6. Please see this link for
steps to take and ways to test for both the POODLE and TLS_FALLBACK_SCSV issues.

http://wiki.centos.org/Security/POODLE
Click to expand...
 
DirectAdmin Support said:
As such we've released a new set of ciphers that we recommend everyone change to use:
http://help.directadmin.com/item.php?id=571
Click to expand...

I have a question that I would like to clarify, I use centos7 and pure-ftpd, and I do not have this file /etc/init.d/pure-ftpd, I saw that, however, is present in /usr/local/directadmin/custombuild, I made ​​the change within this file and then I run again ./build pureftpd. I performed this procedure is correct or changes must be made somewhere else in centos7.

Thanks
 
CentOS 7 uses systemd instead of SysV Init. Please check the options line in /etc/systemd/system/pure-ftpd.service to disable SSLv3.
 
Thank you Martynas, this is below the contents of the file that you suggested but I do not know how to do it in order to secure the service, do you have any other suggestions?

Thanks in advance

# pure-ftpd binary startup for DirectAdmin servers
# To reload systemd daemon after changes to this file:
# systemctl --system daemon-reload
[Unit]
Description=Pure-FTPd FTP server
After=syslog.target network.target

[Service]
Type=forking
PIDFile=/run/pure-ftpd.pid
ExecStart=/bin/sh -c '/usr/libexec/pureftpd_startscript'

[Install]
WantedBy=multi-user.target
Click to expand...
 
Oh, sorry for the confusion :) "OPTIONS" line is located in /usr/libexec/pureftpd_startscript.
 
A version of OpenSSL has been released which adds support for TLS_FALLBACK_SCSV.
Update openssl and restart your services:
Code: 
yum -y update openssl
I've found a few sites that support the proper TLS_FALLBACK_SCSV test, so confirm the SSL ports pass, either by support for TLS_FALLBACK_SCSV, or by disalbing SSLv3.
https://www.ssllabs.com/ssltest/index.html
https://www.tinfoilsecurity.com/poodle

In theory, you don't need to change your ciphers or any of the other settings, but we still recommend it. (we're considering leaving support for SSLv3 out for future versions by default, that issue is still open)
However, I believe the OpenSSL TLS_FALLBACK_SCSV fix requires that clients also support it.. so older clients would still be at risk (bonus point for the move to drop SSLv3 support)

John
 
Thank you for the feedback. Regarding the test site you link to, I would like to recommend https://www.ssllabs.com/ssltest/index.html instead. They also shows if you support TLS_FALLBACK_SCSV, but are clear about that you need to disable SSLv3. My only worry is how many of our shared hosting clients will experience problems, most afraid for emails. :)

Also CentOS is clear about that: "Please note that the updates listed here do not actually FIX POODLE" http://wiki.centos.org/Security/POODLE

So I think I will have to disable it. I hope other users can give feedback if they experience any problems after doing all the changes in your guide at http://help.directadmin.com/item.php?id=571 - I am pretty nervous about disabling it. Will wait until tomorrow.
 
Ok, every hostname reports a mixture of these even though all servers have the same identical httpd-ssl.conf:
This server supports anonymous (insecure) suites (see below for details). Grade set to F.
This server uses SSL 3, with POODLE mitigated. Still, it's recommended that this protocol is disabled.
The server supports only older protocols, but not the current best TLS 1.2. Grade capped to B.
Click to expand...
Whereas if I check the actual domains with the same cert, it only complains about the TLS 1.2 not being enabled?
I don't get it!
 
Try to see if this resolves the issue.. save to a fixPoodle.sh with 755 and run it.
Use with caution.
I make no guarantees. And it is not for all services.
I suggest a more robust coding is needed.
Code: 
#!/bin/sh
#old values: new values: path:
#
grep -q -F 'SSLProtocol All -SSLv2 -SSLv3' /etc/httpd/conf/extra/httpd-ssl.conf \
|| /usr/bin/perl -pi.bck -e 's/SSLProtocol \-ALL \+SSLv3 \+TLSv1/SSLProtocol All \-SSLv2 \-SSLv3/' /etc/httpd/conf/extra/httpd-ssl.conf
#
grep -q -F 'SSLProtocol All -SSLv2 -SSLv3' /etc/httpd/conf/extra/httpd-ssl.conf \
|| /usr/bin/perl -pi.bck -e 's/SSLProtocol All \-SSLv2/SSLProtocol All \-SSLv2 \-SSLv3/' /etc/httpd/conf/extra/httpd-ssl.conf
#
grep -q -F 'ssl_protocols = !SSLv2 !SSLv3' /etc/dovecot/dovecot.conf \
|| echo 'ssl_protocols = !SSLv2 !SSLv3' >> /etc/dovecot/dovecot.conf
#
grep -q -F 'openssl_options = +no_sslv3' /etc/exim.conf \
|| /usr/bin/perl -pi.bck -e 's/tls_require_ciphers = ALL:!ADH:RC4\+RSA:\+HIGH:\+MEDIUM:\-LOW:\-SSLv2:\-EXP/openssl_options = \+no_sslv3\ntls_require_ciphers = ALL:!ADH:RC4\+RSA:\+HIGH:\+MEDIUM:\-LOW:\-SSLv2:\-EXP/' /etc/exim.conf
#
/usr/bin/perl -pi.bck -e 's/#TLSProtocol TLSv1/TLSProtocol TLSv1/' /etc/proftpd.conf
#
yum -y update openssl
service httpd restart
service proftpd restart
service exim restart
 
Last edited:
Some notes:


There are email programs to work with IMAP/SMTP/POP that does not support TLS, only SSL. If you disable SSL on the server you won't be able to use encrypted connection to a mail server any longer.


If to disable SSLv3 in Directadmin you should do it on every server which is added into "Cluster" on Multi Server page, as they won't be able to communicate between each other otherwise.
 
zEitEr said:
There are email programs to work with IMAP/SMTP/POP that does not support TLS, only SSL.
Click to expand...

Yes, in the Advanced tab for Internet e-mail settings in Outlook 2007/2010/2013 it says: "This server requires an encrypted connection (SSL)"

So I assumed Outlook 2007/2010/2013 only support SSL on POP3 for encryption. In fact when checking POP3 with Gmail the settings page only mentions SSL for POP3.

However, this blog explains that TLS 1.0 is sometimes called SSL 3.1. It goes on to say that mail programs that refer to SSL and TLS as separate things cause confusion.

Anyhow, I upgraded openssl using yum on my CentOS 6.5 server, updated DirectAdmin to 1.46.2 and adopted all the changes in http://help.directadmin.com/item.php?id=571.

I notice from my maillog that TLS is being used by POP3 connections and in fact was being used last month:
grep TLS /var/log/maillog-20140928 |more

I can send and receive mail via my server using Outlook 2007 just fine after the changes. If I send to a gmail account I see this in the internet headers:
From Outlook to my server: TLSv1:AES128-SHA:128
From my server to gmail: TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128

This is a great site:
https://www.ssllabs.com/ssltest/index.html

I get A- with the summary of:
  • RC4 cipher is used with TLS 1.1 or newer protocols, even though stronger ciphers are available. Grade reduced to A-.
  • The server does not support Forward Secrecy with the reference browsers. Grade reduced to A-.
  • This server is not vulnerable to the POODLE attack because it doesn't support SSL 3.
  • This server supports TLS_FALLBACK_SCSV to prevent protocol downgrade attacks.

From what I read, TLS_FALLBACK_SCSV isn't particularly useful now because only a minority of browsers support it, notably Chrome (with Firefox to follow next month). However, it could be useful in future because it prevents the fallback problem in general.
 
You must log in or register to reply here.
Back
Top