56

Recently, a new vulnerability in Diffie-Hellman, informally referred to as 'logjam' has been published, for which this page has been put together suggesting how to counter the vulnerability:

We have three recommendations for correctly deploying Diffie-Hellman for TLS:

  1. Disable Export Cipher Suites. Even though modern browsers no longer support export suites, the FREAK and Logjam attacks allow a man-in-the-middle attacker to trick browsers into using export-grade cryptography, after which the TLS connection can be decrypted. Export ciphers are a remnant of 1990s-era policy that prevented strong cryptographic protocols from being exported from United States. No modern clients rely on export suites and there is little downside in disabling them.
  2. Deploy (Ephemeral) Elliptic-Curve Diffie-Hellman (ECDHE). Elliptic-Curve Diffie-Hellman (ECDH) key exchange avoids all known feasible cryptanalytic attacks, and modern web browsers now prefer ECDHE over the original, finite field, Diffie-Hellman. The discrete log algorithms we used to attack standard Diffie-Hellman groups do not gain as strong of an advantage from precomputation, and individual servers do not need to generate unique elliptic curves.
  3. Generate a Strong, Unique Diffie Hellman Group. A few fixed groups are used by millions of servers, which makes them an optimal target for precomputation, and potential eavesdropping. Administrators should generate unique, 2048-bit or stronger Diffie-Hellman groups using "safe" primes for each website or server.

What are the best-practice steps I should take to secure my server as per the above recommendations?

Community
  • 1
Christophe De Troyer
  • 663
  • 1
  • 5
  • 9

3 Answers3

82

From the article you linked, there are three recommended steps to protect yourself against this vulnerability. In principle these steps apply to any software you may use with SSL/TLS but here we will deal with the specific steps to apply them to Apache (httpd) since that is the software in question.

  1. Disable Export Cipher Suites

Dealt with in the configuration changes we'll make in 2. below (!EXPORT near the end of the SSLCipherSuite line is how we'll disable export cipher suites)

  1. Deploy (Ephemeral) Elliptic-Curve Diffie-Hellman (ECDHE)

For this, you need to edit a few settings in your Apache config files - namely SSLProtocol, SSLCipherSuite, SSLHonorCipherOrder to have a "best-practices" setup. Something like the following will suffice:

SSLProtocol             all -SSLv2 -SSLv3

SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

SSLHonorCipherOrder     on

Note: as for which SSLCipherSuite setting to use, this is always changing, and it is a good idea to consult resources such as this one to check for the latest recommended configuration.

3. Generate a Strong, Unique Diffie Hellman Group

To do so, you can run

openssl dhparam -out dhparams.pem 2048.

Note that this will put significant load on the server whilst the params are generated - you can always get around this potential issue by generating the params on another machine and using scp or similar to transfer them onto the server in question for use.

To use these newly-generated dhparams in Apache, from the Apache Documentation:

To generate custom DH parameters, use the openssl dhparam command. Alternatively, you can append the following standard 1024-bit DH parameters from RFC 2409, section 6.2 to the respective SSLCertificateFile file:

(emphasis mine)

which is then followed by a standard 1024-bit DH parameter. From this we can infer that the custom-generated DH parameters may simply be appended to the relevant SSLCertificateFile in question.

To do so, run something similar to the following:

cat /path/to/custom/dhparam >> /path/to/sslcertfile

Alternatively, as per the Apache subsection of the article you originally linked, you may also specify the custom dhparams file you have created if you prefer not to alter the certificate file itself, thusly:

SSLOpenSSLConfCmd DHParameters "/path/to/dhparams.pem"

in whichever Apache config(s) are relevant to your particular SSL/TLS implementation - generally in conf.d/ssl.confor conf.d/vhosts.conf but this will differ depending on how you have configured Apache.

It is worth noting that, as per this link,

Before Apache 2.4.7, the DH parameter is always set to 1024 bits and is not user configurable. This has been fixed in mod_ssl 2.4.7 that Red Hat has backported into their RHEL 6 Apache 2.2 distribution with httpd-2.2.15-32.el6

On Debian Wheezy upgrade apache2 to 2.2.22-13+deb7u4 or later and openssl to 1.0.1e-2+deb7u17. The above SSLCipherSuite does not work perfectly, instead use the following as per this blog:

SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-DSS-AES128-SHA256:DHE-DSS-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!DHE-RSA-AES128-GCM-SHA256:!DHE-RSA-AES256-GCM-SHA384:!DHE-RSA-AES128-SHA256:!DHE-RSA-AES256-SHA:!DHE-RSA-AES128-SHA:!DHE-RSA-AES256-SHA256:!DHE-RSA-CAMELLIA128-SHA:!DHE-RSA-CAMELLIA256-SHA

You should check whether your Apache version is later than these version numbers depending on your distribution, and if not - update it if at all possible.

Once you have performed the above steps to update your configuration, and restarted the Apache service to apply the changes, you should check that the configuration is as-desired by running the tests on SSLLabs and on the article related to this particular vulnerability.

Helmut Wollmersdorfer
  • 103
  • 3
BE77Y
  • 2,577
  • 3
  • 17
  • 23
  • Thank you for this elaborate answer and edit to my post! I appreciate it very much! – Christophe De Troyer May 20 '15 at 10:41
  • No problem - thought it best to generalise both your question and my answer such that any future visitors of this post can get all of the relevant information without having to rely on the external links. – BE77Y May 20 '15 at 10:49
  • 1
    As for the load put on the server by generating the params, you can always generate them on another machine and the simply scp or even copy-paste the file to the target server. There's no need to generate the params in production server. – Erathiel May 20 '15 at 11:26
  • A fair point, @Erathiel - I've edited my post to include that. – BE77Y May 20 '15 at 11:27
  • 2
    After you've changed your configuration, you may want to run a check at [SSLLabs.com](https://www.ssllabs.com/ssltest/) as well just to be sure. – user2428118 May 20 '15 at 12:58
  • @user2428118 another excellent suggestion - I've updated my answer to include that test, and point out the test for this particular vulnerability on the originally-linked article. – BE77Y May 20 '15 at 13:01
  • 2
    Is there a way to fix this vulnerability in Apache/2.2.22 (Ubuntu 12.04)? I appended dhparams.pem to certificate.crt but https://weakdh.org/sysadmin.html still complains – tersmitten May 20 '15 at 14:59
  • 1
    @tersmitten In Apache 2.2.22 versions without backports which you'd find on RHEL/CentOS distributions, your best bet is either to update the package to 2.4 or alternatively just to rely on disabling the 'export' ciphers as well as DH ciphers and using ECDHE in their place as per the above. – BE77Y May 20 '15 at 15:40
  • 2
    @tersmitten That's a completely separate question to this one. – Michael Hampton May 20 '15 at 16:26
  • From the [linked Apache article above](https://httpd.apache.org/docs/current/ssl/ssl_faq.html): "Java 7 and earlier limit their support for DH prime sizes to a maximum of 1024 bits". So, beware of creating a 2048-bit key if you have any clients using Java <= 7 that may need to connect to your servers! – Scott Dudley May 21 '15 at 17:00
  • 3
    you can allways run key generation by 'nice' command. so, you can put it as: nice 19 openssl dhparam -out dhparams.pem 2048 . This will work longer, but will consume only unused cpu time. – Znik Jun 09 '15 at 09:25
  • Java 7 can connect to a server with > 1024 bit DH params, if you have the [java unlimited strength cryptography jars](http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html) installed. The unlimited strength jars do not help Java 6. – Steve Kehlet Aug 21 '15 at 20:12
  • 1
    Great answer, if I could upvote more than once I would. – Chris McKinnel Oct 29 '15 at 14:40
1

Based on a patch of Winni Neessen I've published a fix for Apache/2.2.22 (Debian Wheezy, maybe also usable on Ubuntu): https://flo.sh/debian-wheezy-apache2-logjam-fix/ - thx. for your feedback.

Flo
  • 45
  • 1
  • 3
    this is more a hackish hack than a solution. putting a recent nginx infront of your apache as reverse-proxy would be far more easy, and one doesnt rely on a 3rd-party-apache. – that guy from over there May 21 '15 at 06:37
  • 6
    Why should we trust these binaries? – user May 21 '15 at 12:23
  • 2
    You don't have to trust the binaries; you may recompile apache2.2.x yourself very easily following the steps explained if you take the time. This would furthermore increase your security, because then your setup has unique primary keys. – Flo May 23 '15 at 00:05
  • Would suggest that people don't complain about patches fixing a problem in an opensource software. – Florian Heigl Jun 10 '15 at 02:49
  • @FlorianHeigl I'm not even sure what to make of that comment... – BE77Y Jun 18 '15 at 11:16
-8

Instead of going the complex route of the above 'hacks', consider switching to nginx as your main webserver-software (not just caching or proxy). It obviously seems more up to current standards, security-wise, than the old apache-engines. By using the nginx repository it's giving you a way more up to date stable webserver-engine than apache.

I completely switched over. Saved me a lot of time-consuming problem-solving regarding TLS, and - for our configurations - it also freed up a lot of RAM in the same go. In fact, I found employment of nginx refreshingly simple and straightforward, compared to the myriad of config complications of httpd/apache I had grown accustomed to. Could be a matter of taste, I had become quite fluent in httpd/apache rewrite/config/maintenance before I turned, and it was easier than I feared it would be. There's appropriate recent info on nginx config available online, and its user-base is huge, very active and support-friendly. https://news.netcraft.com/wp-content/uploads/2018/11/wpid-wss-top-1m-share.png

Community
  • 1
Julius
  • 143
  • 3
  • 3
    nginx set up to allow for export ciphers would be *exactly* as vulnerable to the Logjam attack as an Apache server set up to allow for export ciphers. Also, the question asks for solutions in Apache. – user Nov 04 '15 at 11:19
  • Not true. In fact, the main reason I once converted to nginx was precisely because distribution package management, both yum and apt, at the time did *not* supply an up to date version of apache. Whereas the nginx that was supplied included everything I needed against the exploit at the time. Again, it was more up to standards, and I'm guessing its update cycle chain is way shorter. Now it's logjam, but at work I bump into the same issue with apache 2.2 and the distro not supplying a backport against several SSL/TLS related issues. Solution: Replace apache with nginx. Problem solved. – Julius Nov 04 '15 at 14:15
  • 2
    Actually, **solution:** either switch to a distribution that provides more up-to-date packages for software where you absolutely need a newer version (not just backported bug fixes, as is for example the case with Debian or CentOS), *or* build packages yourself from source (it's not hard) and install them using the package manager, *or* plain old install from source code (also not hard, but takes a little more work to manage). For a question that asks "how do I mitigate vulnerability X within Y software?", an answer that states "replace Y software with Z software" is often not a useful answer. – user Nov 04 '15 at 14:36
  • Well, there's still that itsy-bitsy problem called dependencies, plus its not brand new hardware, and aside from it being a system I'm not fixing by changing its distro.version, we have to deal with server-software differences relating to puppet-management. It's not like we have enough time in the world to decide to switch entire OS cores around. One package upgrade (i.e. Apache to Nginx) is doable, in comparison. – Julius Nov 07 '15 at 01:11
  • 1
    Apache to Nginx isn't an upgrade, it's a replacement. Backporting is a possibility. If you have a lot of work invested in the Apache solution, completely throwing that out and replacing it with something else also takes a lot of work. And this question is *still* about solutions centered around *Apache*, not Nginx. I'm not going to spend more time arguing about this; when you post answers, make sure they answer the question as asked at the page top. If you want to post an answer encouraging people to switch from Apache to Nginx, by all means do so, but to a question that allows for Nginx. – user Nov 07 '15 at 11:28
  • As far as the meaning of the word upgrade goes, to me it definitely equaled one. Trying to get an A+ on qualys' ssllabs test using Apache was like opening a can of worms. The switch to nginx made it easy, which too equaled an upgrade from the customer's point of view. Looking at this, it can be seen as an upgrade: http://news.netcraft.com/wp-content/uploads/2015/09/wpid-wss-top-1m-share.png – Julius Nov 07 '15 at 13:13
  • 1
    So properly configuring a software to be secure against known attacks is "a complex route of hacks"? I get A+ on ssllabs.com with a simple apache configuration, you just have to take your time and do some research to understand how to properly configure the software you're using, no hacks over here... – Chazy Chaz May 14 '18 at 03:00
  • So this opinion, which in essence is shared by about 25% of all those serving webpages, gets a -7 rating? I guess the Apache fanboys and girls are a powerful bunch, or the not very well justified anti-Russian sentiments play a role in it. Either way, I'm still not convinced that is deserving in any way. Again, we're 3 years later now, and my advice is even more useful than it was back then. – Julius May 25 '18 at 13:42
  • 2
    @Julius - the downvotes are likely more to do with the lack of value in your answer regarding the question asked, than any hidden "agenda" people apparently might have against nginx vs apache. As it happens, I exclusively use nginx due to my preference - but it was me who answered this question. "Switch to other software" is not an acceptable answer to "how to fix (any problem)". Not to mention, you also entirely missed the point of the actual vulnerability - it was in diffie-hellman key exchange, not apache (or nginx, or sshd, or...) – BE77Y Sep 04 '18 at 14:33