How to fix ‘logjam’ vulnerability in Apache (httpd) – Problems with loading a website are often blamed on the Internet connection, but even the most perfectly set up network cannot help if there is no service to reply at your destination. One of the most popular HTTP servers used for this task is Apache2. Much of Apache’s popularity can be attributed to its easy installation and use, but never the less it is possible to run into problems with even the easiest of the software. If you’ve encountered an issue loading your web page, follow these simple troubleshooting methods outlined in this guide to attempt to get your web server back up and working again. Below are some tips in manage your apache2 server when you find problem about apache-2.2, ssl, apache-2.4, httpd, vulnerability.
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
- 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
- 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.
- 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?
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.
- 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)
- Deploy (Ephemeral) Elliptic-Curve Diffie-Hellman (ECDHE)
For this, you need to edit a few settings in your Apache config files – namely
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
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/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
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:
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.
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.
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.