7

I'd like to have TLSv1.2 support in Apache on my Scientific Linux 6 (RHEL6 rebuild) server.

Is there some semi-supported pathway to getting this working? Preferably with minimal custom rebuilding. Right now I'm using mod_ssl with open_ssl, as provided in the SL6 repositories.

Edit: Once TLSv1.2 support is available, the Apache configuration is well-documented and not too difficult. The problem is that RHEL6 ships with OpenSSL 1.0.0, which only supports TLS through 1.0 or 1.1.

  • mod_gnutls should provide TLS 1.2. You may have to build a recent version of gnuTLS itself tho. – goldilocks Aug 11 '13 at 8:32
  • 1
    It's worth noting, for those coming by way of Google, that SL 6 does (since June 2014) include TLS v1.2 support. Ensure that httpd, mod_ssl, and openssl packages are all up to date and you're good to go. – miken32 Mar 6 '15 at 0:00
10

I've written a quick guide on backporting the OpenSSL 1.0.1 RPM from Fedora Core to support RHEL6 and variants by replacing the bundled 1.0.0 version to add TLSv1.2 and ECC support. Built and tested against CentOS 6.4 in September of 2013:

Guide to OpenSSL 1.0.1 RPM for CentOS 6

Please note: That's the place where I keep my own copy of OpenSSL and OpenSSH up-to-date. Improvements in CentOS 6.5 have largely mitigated the demand for TLS1.2 and flaws like Heartbleed are addressed there, while this answer will forever be stuck in 2013. Don't follow the steps below verbatim, it is imperative you run 1.0.1g or newer.

Now with github: github/ptudor/centos6-openssl

I've made a patch available that I will reference in this guide: openssl-spec-patricktudor-latest.diff

First, prepare your build environment. (If you've installed EPEL, use mock. Keeping it simple here...)

yum -y groupinstall "Development tools" 
yum -y install rpm-build zlib-devel krb5-devel
mkdir -p $HOME/redhat/{BUILD,RPMS,SOURCES,SPECS,SRPMS}
echo "%_topdir $HOME/redhat/" > ~/.rpmmacros

Next, grab the Fedora Core 20 SRPM for OpenSSL and the full OpenSSL source.

rpm -Uvh http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/source/SRPMS/o/openssl-1.0.1e-42.fc21.src.rpm
cd ~/redhat/SOURCES/
wget http://www.openssl.org/source/openssl-1.0.1g.tar.gz
wget http://www.openssl.org/source/openssl-1.0.1g.tar.gz.sha1
openssl dgst -sha1 openssl-1.0.1g.tar.gz ; cat openssl-1.0.1g.tar.gz.sha1

Now apply the old secure_getenv syntax and apply the patch:

cd ~/redhat/SOURCES/
sed -i -e "s/secure_getenv/__secure_getenv/g" openssl-1.0.1e-env-zlib.patch
cd ~/redhat/SPECS/
wget http://www.ptudor.net/linux/openssl/resources/openssl-spec-patricktudor-fc20-19.diff
patch -p1 < openssl-spec-patricktudor-latest.diff

Run the build:

time rpmbuild -ba openssl.spec

Everything went well hopefully, so let's install the new RPMs:

cd ~/redhat/RPMS/x86_64/
sudo rpm -Fvh openssl-1.0.1g-*.rpm openssl-libs-1.0.1g-*.rpm openssl-devel-1.0.1g-*.rpm

Make sure it actually worked:

openssl ciphers -v 'TLSv1.2' | head -4

The link above at my website has more details but this should be a good starting point.

Thanks, enjoy.

20130819: Rawhide revision bumped from 14 to 15.

20130831: fc20 revision bumped from 15 to 18.

20130906: fc20 revision bumped from 18 to 19.

20140408: just go to my website for anything after 1.0.1g.

  • Thanks. I was half-hoping that there'd be a (semi-official) repository with a backport someone would point me to, but it seems that no such thing exists. In which case this approach seems like a pretty viable second choice. – Michael Ekstrand Aug 12 '13 at 17:08
  • Reminder to others, you have to rebuild most programs built against openssl after you replace/upgrade openssl like this. For example nginx is statically linked against some of the libraries and will not work as expected until you rebuild it. – ck_ Sep 8 '13 at 8:49
0

I found this link on ServerFault which covers the setup of TLSv1.2. The Q&A is titled: SSL/TLS 1.2 on Apache with openssl 1.0.1.

These links cover TLSv1.2 info:

Including the following in your httpd.conf should enable TLSv1.2 assuming you have httpd v2.2 or higher and openssl 1.0.1c or higher.

SSLProtocol all -SSLv2

You still need to setup your CipherSuites. This is where it can get confusing. According to the docs above, the only mandatory cipher suite for TLS 1.2 is TLS_RSA_WITH_AES_128_CBC_SHA:

Appendix C. Cipher Suite Definitions
Cipher Suite                            Key        Cipher         Mac
                                        Exchange
TLS_RSA_WITH_AES_128_CBC_SHA            RSA          AES_128_CBC  SHA

This says that the server must provide an RSA certificate for key exchange, and that the cipher should be AES_128_CBC and the Mac SHA.

From the httpd mod_ssl docs, this translates to:

SSLCipherSuite aRSA:kRSA:AES128-CBC:SHA  

You can read about SSLCipherSuites in httpd, here.

In the past I've used my blog post titled: Locking Down SSLv2 in Apache to do this for TLSv1.1. Everything on that page should still be relevant, all you'll need to do is change out the CipherSuites + the versions openssl.

  • With OpenSSL 1.0.1 or later, it's easy. The problem is that RHEL6/CentOS/SL6 doesn't ship with a sufficiently recent OpenSSL. – Michael Ekstrand Aug 12 '13 at 17:09
  • @MichaelEkstrand - why the downvote? – slm Aug 12 '13 at 17:27
  • @sim Because your answer, while good, answers a different question. The problem isn't the Apache configuration; it's getting it working on RHEL6, which ships OpenSSL 1.0.0. – Michael Ekstrand Aug 13 '13 at 17:33
0

I was recently investigating this same issue for a friend, in the context of POODLE.

If you use the latest (AORN) httpd24 build from October 2013 on epel, you will get TLSv1.0 and TLSv1.1 by default. However, as soon as you set SSLProtocol in apache to anything else sensible, you will lose these protocols because of the openssl headers httpd24 was apparently built against.

In practice, this means if you try to disable SSlv2 or SSlv3 explicitly, you implicitly disable TLSv11 an TLSv12.

This is an unfortunate quirk of mod_ssl when you drop down to exactly 1 protocol that it knows about.

The httpd24 in the RedHat "software collections" is built more recently and does not suffer from this problem, it is presumably built against a later openssl (or has a trivial custom patch)

  • Note now that I've blown away my epel httpd24, I cannot confirm this bit implied by the source code: In the 2.4.6 build in both software collections and epel, you should be able to "SSLProtocolDisable -SSLv3" and omit -SSLv2 since SSLv2 will be removed a separate way, giving you back tlsv11 and tlsv12. This tricks mod_ssl into thinking you're supporting multiple protocols. – covener Oct 26 '14 at 0:02

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.