Valid HTML 4.01 Transitional

Responding to the Logjam Attack

James F. Carter <>, 2015-07-14

In the Logjam attack (CVE-2015-4000), a man in the middle induces the victim to use a Diffie-Hellman group (crypto parameter set) with a short key length such as 512 bits. It then cracks this key, steals the session key, and can then eavesdrop on the thru connection. Longer keys can be cracked with more work, but not needing the man in the middle attack. CVE-2015-4000 includes multiple components:

See for an explanation and a browser tester, and ./sysadmin.html for how to generate your own DH params and tighten up your cipher suite, and a server tester. Key points from that howto:

Jimc's judgment of how likely it is that my net will be attacked:

Generating Your Own Diffie-Hellman Group

The server and the client negotiate which variant of Diffie-Hellman key exchange they will use. If the server insists on elliptic curve DH (versus prime field DH), or ephemeral vs. long-lived keys, and the client is unable to do that, then communication is impossible. On the other hand, in prime field DH the server sends the client the group parameters it is going to use, and the client should be able to do what it was told to, unless it has extreme resource limitations, as on a very small embedded device. So it is very likely (but not completely assured) that peers will be able to handle 2048-bit prime field DH groups.

Algorithm incompatibility affects only TLS connections, i.e. HTTPS. Non-HTTP(S) services must also be considered such as SMTP (e-mail) on 587, IMAP (reading mail), and VPNs. Some websites have almost no TLS-protected content, and Logjam mitigation efforts would have almost no consequences, good or bad. But the TLS-protected content, particularly non-HTTP TLS, is very important in my operation, so I will need to watch for and test for algorithm incompatibility. I may go through the upgrade procedure and then find that I need to revert to 1024 bit DH groups. Even so, it's valuable to generate my own 1024-bit DH group.

First you need to generate your 2048 bit DH group. I'm putting it in /etc/ssl/hostcerts, mode 644. The group is sent to remote hackers as part of the protocol, so mode 644 is fine.

openssl dhparam -out /etc/ssl/hostcerts/dhparams.pem 2048
On an AMD G-T40E @1.0GHz (not particularly fast) it took 37 secs. I think entropy starvation is an issue; it took 4 minutes on a faster machine with a lot less network traffic.

I don't have national security or banking secrets to protect, but I figure if I'm going to do the job, I should do it right, so I've made a simple script, run from cron as part of daily housekeeping, that regenerates the DH parameters if older than 30 days (configurable).

# Regenerates our Diffie-Hellman parameters periodically.
# Author: James F. Carter; 2015-07-14
# Uses bash-isms (arithmetic expressions). 

# How old is the DH parm file?  Specify the max age in integer days.
if [ -r $dhfile ] ; then
    mtime=`stat -c %Y $dhfile`
    now=`date +%s`
    if [ $((now-mtime)) -lt $((86400*maxage)) ] ; then exit 0 ; fi
echo "=== Regenerating the Diffie-Hellman group file (crypto)"
mkdir -p /tmp/system
openssl dhparam -out $ 2048 2> /tmp/system/diffie.errs && \
    mv $ $dhfile
ssh-keygen -G $sshfile.can -b 2048 && \
    ssh-keygen -T $ -f $sshfile.can && \
    mv $ $sshfile && \
    rm $sshfile.can

Making Apache Use the DH Parameters

With Apache-2.4.7 and OpenSSL-0.9.8a (or later) you can append the parms to the end of your host certificate file. With Apache-2.4.8 and OpenSSL-1.0.2 (or later) you can specify:

SSLOpenSSLConfCmd DHParameters "/etc/ssl/hostcerts/dhparams.pem"

In OpenSuSE 13.1 we have Apache-2.4.6-6.47.1 and openssl-1.0.1k . Apache-2.4.6 cannot do SSLOpenSSLConfCmd (syntax error or unsupported extension). And DH parameters were not used when appended to the host certificate. I'm using a concatenated file with the key, cert, and authorities (in that order). DH parameters after the cert, or at the end, both were not used. Sometimes important fixes are backported to the official distro version, but that has not happened (yet, as of 2015-07-15). Now what?

OpenSuSE Tumbleweed and the 13.1 Apache sub-repo are on apache-2.4.12. Tumbleweed is on OpenSSL 1.0.2d. 13.1 does not have any official-looking subrepo for 1.0.2, though 5 developer homesites have it. 13.1 and 13.2 are on 1.0.1k. I could install 13.1:Apache:apache-2.4.12. I would first try installing Tumbleweed's OpenSSL-1.0.2d, but if there were incompatible dependencies I would guess which community developer was the most reliable and install his/her package for 13.1. But do I want to do this, to be my own distro manager? I would not get SuSE patches for other future issues, until I upgraded to the distro version after 13.2, which is a big minus. I'm going to temporize: continue with the research.

This knowledge base article about SuSE Linux Enterprise Server (2015-05-27) has these points:

Ivan Ristic, a well-respected developer for SSL issues, has posted an article about how to improve DH parameters in Apache (2013-08-xx). He has a link to the Apache Bugzilla issue which may be the one adding the ability to append DH parameters to the host certificate. The patch applies to and compiles with Apache-2.4.6.

According to this blog post by Emilia Kasper (OpenSSL) (2015-05-20), the OpenSSL people are going to raise the minimum DH key length to 768 bits in the next release (I think that's 1.0.1k which OpenSuSE has already pushed out), and 1024 bits soon thereafter. The blogger's report of the WeakDH results: precomputation for 512 bits costs under 1e5 hours (divided by number of CPUs x cores). A lot, but achievable. To break 1024 bits costs 4.5e7 core*years. Special purpose hardware, such as used in Bitcoin mining, could speed this up.

SuSE's incident report bug for Logjam: In comment 21, Marcus Meissner posts a test command line:

openssl s_client -connect -cipher DH </dev/null > /tmp/errs 2>&1
If your openssl (as a client) is vulnerable, it connects. If not vulnerable you get an error message about "dh key too small" and no ciphers are negotiated. The current SuSE version openssl-1.0.1k-11.72.1 is not vulnerable. This version is announced in comment 24.

TLS in Apache and Other Software

As for browsers, these are not vulnerable, meaning that they will refuse 512-bit DH groups: Firefox-38.0.1 dated 2015-07-13 for desktop Linux, Firefox-39.0 dated 2015-07-02 for Android, and Safari (version and date not known, probably similar) for iOS (Apple). Slightly earlier versions might also be not vulnerable. Other vendors' products are also receiving updates to mitigate Logjam, but I don't have them installed. As a client, the browser uses the DH group that the server sends to it.

Here is a list of crypto enabled services, mostly from What software might have been overlooked? Instant message and VOIP clients and servers are notably absent. It would be really nice if /etc/ssl/openssl.cnf could provide TLS parameters for all apps using OpenSSL, and similarly for GnuTLS, but that's not the way it works.

Apache Web Server

In /etc/apache2/conf.d I have a file that I include in each virtual host that does TLS, with generic configuration. Otherwise you should look for these directives in the various VirtualHost sections, or in the toplevel server configuration if your entire site uses TLS (which is recommended). See your Apache manual for all the details.

SSLCipherSuite "$list" , where the list finally decided on may be found later under Cipher List Review.
SSLHonorCipherOrder On (use the server's order, not the client's).
SSLOpenSSLConfCmd DHParameters "/etc/ssl/hostcerts/dhparams.pem" ; but the patch introducing this command requires Apache-2.4.8 and OpenSSL-1.0.2 or later, which OpenSuSE-13.1 does not (yet) have.

Postfix (SMTP)

Edit/add these to /etc/postfix/
smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, 3DES, RC4, MD5, PSK, DSS, CAMELLIA, SEED, SRP, AES256
smtpd_tls_dh1024_param_file = ${config_directory}/dhparams.pem

This exclusion list was custom edited by jimc to reproduce the Apache list as close as possible. In particular, AES(256) is overkill at present; AES(128) gives plenty of security. It is possible to copy the Apache cipher list into tls_$TYPE_cipherlist, but the documentation strongly advises to leave the default cipherlists alone, just excluding troublesome ciphers.

Dovecot (IMAP)

Edit/add to /etc/dovecot/conf.d/10-ssl.conf
ssl_cipher_list= (same as for Apache)
ssl_prefer_server_ciphers = yes
ssl_dh_parameters_length = 2048 (it regenerates them once a week)
(to reload: doveadm reload; systemctl reload dovecot does not know about doveadm)

The latter two require >= version 2.2.6, we have 2.1.17 .


Jethro Beekman provides recommendations for key exchange algorithms in OpenSSH. Suggested mitigating steps include:


The builtin DH parameters cannot be changed. However, in this forum post by Martin Willi (StrongSwan, 2015-05-21), he says that StrongSwan's TLS implementation prefers 2048 bit primes if agreed by both ends. The next release will reject groups smaller than 1024 bits. He is not aware of any proposal downgrade attack against IKE, analogous to the Logjam attack against HTTPS and normal TLS connections.

In any connection stanza in /etc/ipsec.conf, specifically conn %default, you can set esp = cipher,suites and similarly for ike. The available cipher suites and their names are documented in a link from StrongSwan's ipsec.conf documentation; generally the reasonable ciphers from OpenSSL (and others) are available. As reviewing the cipher list of the OpenSSL software is already a lot of work, I'm going to rely on the prudence of the StrongSwan developers in setting policies for cipher selection.


The configuration file /etc/openvpn/server.conf (various basenames) includes the dh parameter; specify your custom parameter file instead of dh1024.pem provided with the package. For the tls-cipher parameter, copy the cipher list from Apache (colon separated).

OpenLDAP (Server)

The OpenLDAP (2.4) Administrator's Guide, TLS section, gives these relevant directives to go in the [global] section of /etc/openldap/slapd.conf . The given URL refers to TLSEphemeralDHParamFile but the correct parameter name is TLSDHParamFile, see this bug report.

If you are using dynamic configuration, you would add these equivalents to /var/lib/ldap/slapd.d/cn\=config.ldif . Typically /var/lib/ldap/slapd.d is the referent of a symbolic link /etc/openldap/slapd.d . ldapadd is recommended rather than editing the file directly.

ldapmodify -x -D 'cn=config' -y /etc/openldap/root.secret -H ldapi:/// <<EOF
dn: cn=config
changetype: modify
add: olcTLSDHParamFile
olcTLSDHParamFile: /etc/ssl/hostcerts/dhparams.pem
add: olcTLSCipherSuite

Change add to replace if the parameter is already present.

You also need to add to /etc/openldap/ldap.conf, for use by ldapsearch, ldapmodify and associated utilities:
TLS_CIPHER_SUITE $list (copy from Apache except colon separated)

As clients, these utilities use the DH group sent out by the server.

Not a Logjam issue: the intermediate certificate(s) that signed the server's host cert need to be in the trust store (/etc/ssl/certs and friends) so slapd can append them to the host cert during session initiation.

ldap_nss (Client)

In /etc/ldap.conf edit or add:
tls_ciphers $list (copy from Apache except colon separated)

The client uses the DH group sent out by the server.

TLS_CIPHER_SUITE, documented in the man page for ldap.conf, is for /etc/openldap/ldap.conf and the server utilities such as ldapsearch.

Testing (before mitigation) at Qualys:

Cipher List Review

Logjam does not include an essential element of weak session ciphers, but since I need to adjust the cipher list anyway to make sure ECDHE is preferred in all cases, I'm taking this opportunity to upgrade and document the session ciphers and MAC algos.

I started with Scott Helme's recommended list and hacked from there. Ivan Ristic used to make a recommendation, but I'm guessing he got tired of people acting like script kiddies, installing his list, getting burned, and complaining. The Mozilla Server Side TLS recommendation is also helpful. They make a good point that you need to consider your client base: if you can rely on everyone having up-to-date clients you should keep only TLSv1.2 ciphers. If you have clients from the previous generation, like Android before KitKat, Microsoft Internet Explorer 10 and earlier, Apple Safari on OSX, or OpenSSL 0.9.8, then you need enough SSLv3 ciphers to make TLSv1.0 work. If you are required to deal with clients on Windows XP, you will need to scrape the bottom of the barrel, with reduced security.

But handles Postfix ciphers differently: take the OpenSSL default and exclude troublesome ciphers. I was attracted to this approach so if new ciphers are added to OpenSSL, I will automatically use them, and if algos are deprecated I will not be asking for them by name and forcing them into my cipher list. I came up with a list of terms that almost exactly duplicate what I had picked out for the previous hacked list. Here they are:

The default ordering puts ephemeral DH ahead of DH with the host key, giving perfect forward security. ECDH suites use the 256 bit curve. The best cipher that will actually be used on my servers is ECDHE-RSA-AES128-GCM-SHA256. GCM (Galois Counter Mode) is harder to crack than other modes, plus it gives intrinsic integrity, equivalent to the listed MAC type. CTR mode is also good.

The final cipher list is:


Action Plan

I will not upgrade Apache. Instead I will hope that OpenSuSE will backport for 13.1 (Apache-2.4.6) one of the solutions that allow custom DH parameters to be used. My justification is:

I will configure other software that already accepts custom DH parameters, first trying a 2048 bit prime, but falling back to 1024 bits if interoperability problems ensue. In the likely case that software such as StrongSwan gets the ability to use custom DH parameters, I will upgrade and configure them.

In particular, I will add OpenSSH to my DH parameter regeneration script.

I will install the new cipher list everywhere. Specifically, RC4 is out.

What Was Accomplished

Here is a generic command to test connections to a port with intrinsic TLS:

openssl s_client -connect$PORT -CApath /etc/ssl/certs
Look for using our best cipher, which is currently ECDHE-RSA-AES128-GCM-SHA256. GCM is harder to crack than other modes, plus it gives intrinsic integrity, equivalent to the listed MAC type. CTR mode is also good. Look for a key exchange algo of ECDHE (elliptic curve Diffie-Hellman, ephemeral).