A secure SSLCipherSuite

Arieh · Aug 18, 2010

A friend of mine pointed out that my ssl website wasn't fully secure because it was accepting low Cipher Suites, 128 and lower. I ran some ssl tester on my domain and it also came with the suggestion to change this.

What I first tried is changing the SSLCipherSuite setting in /etc/httpd/conf/extra/httpd-ssl.conf, but that didn't seem to have effect on the other virtual hosts (as explained here http://www.directadmin.com/forum/showthread.php?p=180572#10).

So if you don't want to accept (most) 128bit and lower, and be secure and cool you could change the existing SSLCipherSuite, and also add it to the bottom of /etc/httpd/conf/extra/httpd-ssl.conf:

SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM

Giving me a score of 88 at https://www.ssllabs.com/ssldb/index.html

Edit June 2, 2012:
Use these lines instead, they will fix the BEAST issue.

Code:

SSLProtocol -ALL +SSLv3 +TLSv1
SSLHonorCipherOrder On
SSLCipherSuite RC4-SHA:HIGH:!ADH
SSLInsecureRenegotiation off

So comment out the existing SSLCipherSuite, add the new lines, and be sure to add them at the bottom of the file as well. If anyone knows a better configuration, please share.

Edit October 15, 2014:

In case anyone arrives at this topic; I recommend this page: https://wiki.mozilla.org/Security/Server_Side_TLS#Apache

nobaloney · Jun 3, 2012

I just tried this, and ran the test at ssllabs, and it still says I'm vulnerable on two machines I tested; one running Apache 1 and one running the latest Apache 2.

What might I be doing wrong?

Jeff

Arieh · Jun 3, 2012

Be sure to have it twice in the config file (one time outside the </virtual host>, also check on duplicate entries of all the lines who may override.

Other then that, you could maybe check the output of

Code:

openssl s_client -connect www.yourssldomainhere.tld:443 | grep "Cipher is"

it should return New, TLSv1/SSLv3, Cipher is RC4-SHA

Other things I can think of: old version of openssl, and Apache 1 might not support the same config. But both RC4-SHA and SSLv3/TLSv1 are very old so I wouldn't think that's a problem.

ditto · Jun 3, 2012

@Jeff, did you remember to click "Clear cache" link just below the header text? If not it will show cached result from before your changes.

@Arieh, I don't have it twice in the config file, I only have added it at the bottom after </virtual host>, and it works great. And also of course I did comment out the existing line that now looks like this:

#SSLCipherSuite ALL:-ADH:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP

Arieh · Jun 3, 2012

@ditto, that sounds about right, I do wonder though if and where the setting inside the <VirtualHost _default_:443> will be used for. Probably nowhere, but it seemed right to modify all lines to the correct ones.

A general note on this. First I should mention the source to which the credits belong: https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls

The beast attack has been fixed in TLS 1.1+, below that you will have to stick with RC4. It's not really a problem, because it's an old and widely supported cipher. Its encryption isn't the strongest, but it will do.

TLS 1.1 & TLS 1.2 have been added in openssl 1.0.1-stable - but it's not commonly used on servers, and not that many clients either.

You can check what version you have by the command openssl version.

If you do support TLS 1.1/1.2, you can use the following SSLCipherSuite;

Code:

SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH

The idea is that you put a few TLS 1.2 cipher suites first so that they can be picked up by TLS 1.2 clients, which are not vulnerable, followed by RC4 for TLS 1.0 clients.

Something else noteworthy:

Enabling the empty fragment technique server-side (details for OpenSSL here) does not work either. TLS 1.0 uses two initialisation vectors (IVs), one each for client- and server-side of the communication channel. The vulnerability exploited by BEAST is on the client-side and cannot be addressed by making server-side changes to how data is sent.

I first thought this openssl fix was a genuine fix, but disabled in apache (and exim) for compatibility reasons and thus not used, but that seems not fully the case.

I decided to use RC4-SHA on all services I'm using ssl with: apache/exim/dovecot/(proftpd)/directadmin

Exim already recommended the use of RC4-SHA.

Below a list of configs and the config lines to look for

Exim:
/ect/exim.conf - tls_require_ciphers

Code:

tls_require_ciphers = RC4-SHA

Test it:
openssl s_client -connect server.name.here:587 -starttls smtp | grep "Cipher is" Note the -starttls option is not supported in all version of the tool

Dovecot:
/etc/dovecot.conf - ssl_cipher_list

Code:

ssl_cipher_list = RC4-SHA

openssl s_client -connect server.name.here:993| grep "Cipher is"

DirectAdmin
/usr/local/directadmin/conf/directadmin.conf

Code:

ssl_cipher=RC4-SHA

openssl s_client -connect server.name.here.nl:2222 | grep "Cipher is"
(or other ssl port if u configured)

Proftpd should be TLSCipherSuite - but I don't use it.

openssl s_client -connect server.name.here:22 -starttls ftp

errors by openssl like unable to get local issuer certificate can be ignored.

Please note:
Modify at own risk. If anyone has thoughts or information on this, please share.

nobaloney · Jun 4, 2012

Arieh said:
Be sure to have it twice in the config file (one time outside the </virtual host>, also check on duplicate entries of all the lines who may override.

I now have it twice in the config file and I've checked to make sure there's no duplicates. It's now working on the system running Apache 2, but the system running Apache 1 still has the error.

Code:
Other then that, you could maybe check the output of

Code:

openssl s_client -connect www.yourssldomainhere.tld:443 | grep "Cipher is"

This is probably the problem...

it should return New, TLSv1/SSLv3, Cipher is RC4-SHA

It doesn't; it returns New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA

Other things I can think of: old version of openssl, and Apache 1 might not support the same config. But both RC4-SHA and SSLv3/TLSv1 are very old so I wouldn't think that's a problem.

Most likely is older version of openssl; this test server is running CentOS4.9, and it's not getting updates anymore.

I'm looking at this how-to, dated 2003: http://www.directadmin.com/forum/showthread.php?t=163&page=1

A quick look shows that following it (with a bit of common sense; for example version numbers), it shouldwork to update this server. What do you think?

Or does anyone else have a newer RPM which will work on CentOS 4?

Jeff

nobaloney · Jun 4, 2012

ditto said:
@Jeff, did you remember to click "Clear cache" link just below the header text? If not it will show cached result from before your changes.

Thanks, ditto. That caught me for a few minutes, but it wasn't the problem.

@Arieh, I don't have it twice in the config file, I only have added it at the bottom after </virtual host>, and it works great. And also of course I did comment out the existing line that now looks like this:

#SSLCipherSuite ALL:-ADH:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP[/QUOTE]
As did Arieh, I've put it in both places.

Please see my reply to Arieh, immediately above.

Thanks.

Jeff

Arieh · Jun 4, 2012

To be sure its openssl, you can check with

Code:

openssl ciphers -v | grep RC4-SHA

which returns for me:

Code:

RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1

I guess you would indeed need to compile it from source. I do wonder, why you maintain such an old setup, is there special software running?

nobaloney · Jun 5, 2012

I get this; can you point out anything I can do short of an install from source?

Code:

# openssl ciphers -v | grep RC4-SHA
DHE-DSS-RC4-SHA         SSLv3 Kx=DH       Au=DSS  Enc=RC4(128)  Mac=SHA1
EXP-KRB5-RC4-SHA        SSLv3 Kx=KRB5     Au=KRB5 Enc=RC4(40)   Mac=SHA1 export
KRB5-RC4-SHA            SSLv3 Kx=KRB5     Au=KRB5 Enc=RC4(128)  Mac=SHA1
RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1
EXP1024-DHE-DSS-RC4-SHA SSLv3 Kx=DH(1024) Au=DSS  Enc=RC4(56)   Mac=SHA1 export
EXP1024-RC4-SHA         SSLv3 Kx=RSA(1024) Au=RSA  Enc=RC4(56)   Mac=SHA1 export
#

Because we manage servers for different clients running different server versions, some of whom require certain versions, and some of whom don't want the expense or downtime of moving to new OS distributions, we maintain several testbed servers, which we use for testing various distributions/upgrades/changes, etc.

I'm going to do a sample install from source rebuild of openssl in the next day or two to make sure it doesn't break anything; then we'll update clients if necessary.

Thanks.

Jeff

Arieh · Jun 5, 2012

Well RC4-SHA is available by looking at that list. That one line is an exact match.

I've given it a try to compile the latest version, 1.0.1c on cloudlinux, which would be the same as centos 6.

I've used this config line

./config --prefix=/usr shared zlib-dynamic
make
make test
make install

ldconfig
openssl version
OpenSSL 1.0.1c 10 May 2012

do take a look at /usr/lib/libssl.so & /usr/lib/libcrypto.so (as described in that year 2003 tutorial)
for me they are
/usr/lib/libssl.so -> /usr/lib64/libssl.so
/usr/lib/libcrypto.so -> /usr/lib64/libcrypto.so

it does work, but then it breaks openssh. I had to recompile that as well. The rpm does not seem to pick up the new openssl (I tried a yum reinstall).

Also apache should be recompiled, and I would think all services requiring ssl.

I gave this a try to see if I get TLS 1.1/1.2 working, and it does work. Though I believe chrome and firefox and possible IE are caching its encryption method (even after closing & restarting the browser), which had me confused for a while. But now it uses the same encryption as facebook and google

So one more time the complete config lines for tls 1.1, if anyone wants it.

Code:

SSLProtocol -ALL +SSLv3 +TLSv1
SSLHonorCipherOrder On
SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH

But I should warn about openssl, if it's not really needed I would avoid recompiling it. If RC4-SHA is listed like you pasted, I would think thats not the issue but I'm not sure, and I would then wonder what the actuall reason would be for it not working.

SeLLeRoNe · Jun 6, 2012

If can help, update.script (present on this forum) easly install OpenSSL and OpenSSh from source without much pain.

Regards

nobaloney · Jun 6, 2012

@Arieh:

You're losing me a bit but I did check and here's what my links are on this 32-bit box:

Code:

lrwxrwxrwx  1 root root 26 Feb  2 05:07 libssl.so -> ../../lib/libssl.so.0.9.7a
lrwxrwxrwx  1 root root 29 Feb  2 05:07 libcrypto.so -> ../../lib/libcrypto.so.0.9.7a

I took SeLLeRoNe's advice and used the update.script to update openssl and openssh, but when I went to rebuild apache I get an error:

Code:

sl_util_sdbm.o ssl_util_sdbm.lo
ssl_util_ssl.c: In function `SSL_X509_isSGC':
ssl_util_ssl.c:327: error: `STACK' undeclared (first use in this function)
ssl_util_ssl.c:327: error: (Each undeclared identifier is reported only once
ssl_util_ssl.c:327: error: for each function it appears in.)
ssl_util_ssl.c:327: error: `sk' undeclared (first use in this function)
ssl_util_ssl.c:336: error: syntax error before ')' token
ssl_util_ssl.c:337: error: syntax error before ')' token
ssl_util_ssl.c:341: error: break statement not within loop or switch
ssl_util_ssl.c: At top level:
ssl_util_ssl.c:345: error: syntax error before '}' token
make[4]: *** [ssl_util_ssl.lo] Error 1

And now apache fails and restarting it gives me a segmentation fault

. So I'm now working on that. Maybe time to rebuild the box.

Jeff

SeLLeRoNe · Jun 7, 2012

What apache version?

Ive googled a bit ans seems to be an incompatiblity with mod_ssl so ive just one idea, probably or you using old apache, or the "compiled" one version in custombuild folder has not been cleaned so the build script is not decompressing it again.

Maybe:

Code:

cd /usr/local/directadmin/custombuild
rm -rf httpd*
./build clean
./build update
./build apache

Should work, but, is just a guess

Regards

Arieh · Jun 7, 2012

Those libssl.so and libcrypto.so shortcuts should after the new install link to the new files, though I'm not sure when they're actually used.

But its indeed quite easy to run into problems with it. I can imagine with older versions of everything its even easier.

Someone here had the same error after newer openssl and apache 1.3 http://www.directadmin.com/forum/showthread.php?t=39335&page=1 - but he then upgraded to ap2 as a fix.

But I do wonder if apache 1.3 could still provide a up to date secure connection? I thought it wasn't supported anymore. It should work, but wouldn't there be any new security issues that won't be fixed? Or maybe there are some unofficial forks?

paul-w · Apr 9, 2014

ditto said:
And also of course I did comment out the existing line that now looks like this:

#SSLCipherSuite ALL:-ADH:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP

Just a quick update. If I don't comment out the above SSLCipherSuite setting and just append it to the end of /etc/httpd/conf/extra/httpd-ssl.conf then I get an A- score on https://www.ssllabs.com/ssltest which is good enough for me.

ditto · Apr 9, 2014

@paul-w, It is not needed to make that change anymore. In recent DirectAdmin versions there has been changes/improvements. You might need to do ./build rewrite_confs to get all the good changes. I am also getting a A-

Here is the latest good stuff from changelog, but it has been other improvements too in previous versions: http://www.directadmin.com/features.php?id=1555

A secure SSLCipherSuite

Arieh

Verified User

nobaloney

NoBaloney Internet Svcs - In Memoriam †

Arieh

Verified User

ditto

Verified User

Arieh

Verified User

nobaloney

NoBaloney Internet Svcs - In Memoriam †

nobaloney

NoBaloney Internet Svcs - In Memoriam †

Arieh

Verified User

nobaloney

NoBaloney Internet Svcs - In Memoriam †

Arieh

Verified User

SeLLeRoNe

Super Moderator

nobaloney

NoBaloney Internet Svcs - In Memoriam †

SeLLeRoNe

Super Moderator

Arieh

Verified User

paul-w

Verified User

ditto

Verified User