Responding to the Logjam Attack

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:

• The TLS protocol has inadequate protection for the crypto proposal exchange, so the attacker can lie that the intended peer wants to use a 512-bit Diffie-Hellman group and the victim will accept it.
• The vast majority of TLS installations use Diffie-Hellman groups provided with the software package and/or published in relevant RFCs. That is, they're all using the same groups.
• The attacker can precompute helper information about the group, and can then very rapidly crack any key from that group. Individual hackers can do the precomputation for 512 bit groups, a university research group can get enough CPU power to do 768 bits, and a national security agency is believed to have succeeded with a 1024 bit group.

See https://weakdh.org/ 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:

• A university research group such as theirs has enough CPU power to crack 768 bits, and a national security agency can do 1024 bits, and is inferred from leaked material to have actually done it and used the results extensively.
• In the cracking procedure, the early and most time-consuming steps yield data about the DH group that can be re-used to quickly crack any key in that group. Crypto products generally come with DH groups preinstalled and it's rare for the sysop to replace them. If they invested the resources to precompute just two DH groups they could get instant access to TLS connections to almost half of popular websites. Other server products using crypto, like SSH, OpenVPN and StrongSwan (IPSec VPN), have the same weakness,
• Generating your own DH group is recommended, with a 2048 bit prime.
• Frequent regeneration of the DH group can be considered by extra paranoid sysops. If the adversary records your traffic, then cracks your DH group, all traffic using keys from that group can be read. Less secret material is revealed if the DH group is replaced on a schedule.
• Against ECDH (Elliptic Curve Diffie-Hellman), precomputation is much less useful. Your cipher list should prefer ECDH or should exclude prime field Diffie-Hellman key exchange entirely.
• Although weak ciphers beyond DH are not an essential element of Logjam, you should take this opportunity to review your cipher list for best practices.

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

• The proposal downgrade component requires a man in the middle attack. For a residential common carrier net this is not too likely (except national security targets), whereas a public wi-fi hotspot has to be assumed to be in collusion with hackers, so the man in the middle is always working on your packet stream. Likely many hackers are cooperating to precompute commonly used 512 bit DH groups. Thus I feel the proposal downgrade attack as a threat that needs to be responded to. But the downgrade necessarily faces my clients, e.g. web browser or mail reader, which have Logjam mitigation patches and are verified to reject 512 bit groups.

• For precomputing hack data for a normal-length DH group, e.g. 768 or 1024 bits, the adversary needs to put a lot of CPU hours into the project, which costs him money and time. When the objective is to steal credentials to an ordinary citizen's financial institution, an attack against normal-length DH groups is not likely to be profitable. On the other hand, in the national security context, for industrial espionage, or for subverting POS terminals in an entire retail organization, the payload could be much more valuable.

• It is very unlikely that my connections might come to the attention of an organization with the resources to attack a normal-length DH group. Even so, that might change with an unforseen event. And the paradigm in crypto is, if a breach is possible, even though unlikely, it ought to be plugged. Thus I am going to continue in this project and strengthen my DH defenses, in multiple ways for defense in depth. But some software cannot yet be upgraded without excessive work or without sacrificing security elsewhere. I will not lose sleep over unfinished items.

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

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).

#!/bin/bash
# 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.
maxage=30
dhfile=/etc/ssl/hostcerts/dhparams.pem
if [ -r $dhfile ] ; then
    mtime=`stat -c %Y $dhfile`
    now=`date +%s`
    if [ $((now-mtime)) -lt $((86400*maxage)) ] ; then exit 0 ; fi
fi
echo "=== Regenerating the Diffie-Hellman group file (crypto)"
mkdir -p /tmp/system
openssl dhparam -out $dhfile.new 2048 2> /tmp/system/diffie.errs && \
    mv $dhfile.new $dhfile
sshfile=/etc/ssh/moduli
ssh-keygen -G $sshfile.can -b 2048 && \
    ssh-keygen -T $sshfile.new -f $sshfile.can && \
    mv $sshfile.new $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:

• Apache on SLE11 (what version?) cannot accept modified DH parameters. If you use apache2-mod_nss (vs mod_ssl), it can only do ECDH which is not vulnerable.
• Apache on SLE12 (what version?) can handle DH parameters appended to the host cert. (Jimc says: this must be Apache-2.4.7.)
• OpenVPN configuration has the "dh" parameter. Use it.
• StrongSwan: The provided DH parameters cannot be changed, hiss, boo! But see below for mitigation.
• OpenSSH: As configured by SuSE, ECDH is used by default, so is not affected. It's possible to configure a minimum group size also.

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 dhe512.zmap.io:443 -cipher DH </dev/null > /tmp/errs 2>&1

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 weakdh.org. 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/main.cf
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 .

OpenSSH

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

• In /etc/ssh/sshd_config modify the KexAlgorithms parameter, a comma-separated list all on one line. See the reference for the recommended algos.
• List Elliptic Curve Diffie-Hellman (ECDH) algos first; they are not vulnerable to Logjam and use less CPU for the same security than finite field DH. Assuming the peer supports ECDH.
• The currently recommended best elliptic curve is curve25519-sha256@libssh.org but you need openssh-6.7 or later to use it without bugs.
• diffie-hellman-group1-sha1 uses a fixed 1024-bit prime which is assumed to be compromised. Remove it from the list. diffie-hellman-group14-sha1 uses a fixed 2048-bit prime and can be listed last, as a fallback.
• If you want to allow finite field DH, include the group-exchange algos. These will pick a group (of the preferred or closest available size) at random from /etc/ssh/moduli.
• (Jimc says:) /etc/ssh/moduli is distributed with the software, but it is recommended that you generate your own group(s) using this procedure. -b 2048 sets all the groups to have 2048 bit primes.

  ssh-keygen -G moduli.can -b 2048 && \
  ssh-keygen -T moduli.new -f moduli.can && \
  mv moduli.new moduli

• (Jimc picked up:) The client's preference order governs, so the server can only exclude algos. Edit the client's /etc/ssh/ssh_config if the client is picking a disfavored but not excluded algo.

StrongSwan

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.

OpenVPN

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.

• TLSDHParamFile $filename
• TLSCipherSuite $list (copy from Apache but colon separated)

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.

• olcTLSDHParamFile: $filename
• olcTLSCipherSuite: $list (colon separated, copy from Apache)

    
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
olcTLSCipherSuite: DEFAULT:+aRSA:+SHA:!aNULL:!DES:!3DES:!RC4:!MD5:!PSK:!DSS:!CAMELLIA:!SEED:!SRP:!AES256
-
EOF

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 simba.math.ucla.edu (before mitigation) at Qualys:

• Overall grade: B
• Subscores: certificate 100, protocol support 70, key exchange 80, cipher strength 90
• Allows weak DH parameters (Logjam, grade limited to B).
• Accepts RC4 (grade limited to B). RC4 is enabled deliberately, as a last resort. It's only used for IE6 and IE8 on Windows XP (or by hackers). Can we toss this?
• Can't test Jacinth because ports other than 443 are not supported, but it's configured the same as Simba.

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 weakdh.org 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:

• DEFAULT -- This approach starts with everything OpenSSL currently offers, excluding eNULL (no encryption).
• +aRSA -- Puts RSA certs later than ECDSA, if available. I don't presently have ECDSA certs on my servers, but I would like to get and use them.
• +SHA -- Puts suites with a SHA-1 MAC later than all others.
• (not) !SHA -- Suppress SHA-1 suites entirely. 160 bit SHA-1 is at the end of its life. Suppressing it would give you pure TLSv1.2, which produces the best security but cuts off too many clients in my situation.
• !aNULL -- Suppresses anonymous DH, tossed 4 ciphers.
• !DES:!3DES:!RC4:!MD5 -- IE8 on Windows XP needs 3DES or RC4, but I don't have any such clients. I used to allow RC4 (deprecated) as a last resort for IE6 on Windows XP, but that OS is long dead in my client base, so likewise for RC4. A few SSLv3 ciphers use MD5.
• !PSK -- Pre-shared keys, tossed 1 cipher.
• !DSS -- DSS certs are rare and at 1024 bits are at end of life. Tossed 2 ciphers.
• !CAMELLIA:!SEED -- These aren't bad, but Rijndael (AES) won the competition.
• !SRP -- This is an alternative to Diffie-Hellman which has been incubating since 1998. It's an interesting concept but I have enough going on without dealing with an unfamiliar KEx algo with little client support and only available in SSLv3. Tossed 1 cipher.
• !AES256 -- Presently AES128 is plenty; AES256 is overkill. I'm simplifying my life by excluding it across the board.

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:

DEFAULT:+aRSA:+SHA:!aNULL:!DES:!3DES:!RC4:!MD5:!PSK:!DSS:!CAMELLIA:!SEED:!SRP:!AES256

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:

• It is very unlikely that I will come to the attention of an adversary with the capability to deploy Logjam against 1024-bit keys.
• The protected secrets are not profitable to the usual web adversary, nor to the kind of adversary who would have the resources to deploy Logjam.
• It is quite likely that SuSE will do the backport promptly.
• It's a major security loss if I lose contact with fixes for future issues on which I am more likely to be attacked.

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 simba.math.ucla.edu:$PORT -CApath /etc/ssl/certs

• A housekeeping script was created which rebuilds the OpenSSL and OpenSSH DH group files every 30 days.

• Apache web server: I posted a comment to OpenSuSE bug 931723 joining with others to request that one of the additions, enabling a local DH group file to be used, be made available in the stock Apache for OpenSuSE-13.1. It looks like SuSE already intended to make this happen.

  Apache already had a strong cipher list (except allowing RC4 as a last resort for IE6 and IE8 on Windows XP) and already prefers ECDHE. The improved cipher list was installed.

  Generic test on port 443: works with ECDHE-RSA-AES128-GCM-SHA256

  Testing simba.math.ucla.edu with the new cipher list at Qualys.

  • Overall grade: B
  • Subscores: certificate 100, protocol support 70, key exchange 80, cipher strength 80
  • Allows weak DH parameters (Logjam, grade limited to B). It doesn't like any of the prime field DH ciphers due to using a 1024-bit prime, and using the one that comes with the sofware rather than a custom group. Mitigation will have to wait until SuSE backports a patch.
  • Handshake simulations: communication is not possible for IE6 or IE8 on Windows XP.
  • The BEAST attack is not mitigated on the server. Non-mitigation is currently recommended because it requires RC4, whose weakness is a worse security hazard. Rely on client-side mitigation, deployed in all up-to-date browsers.

• Postfix mail transport agent: The custom group file was configured, but the documentation strongly advises against monkeying with the cipher list (tls_$type_cipherlist), so I merely excluded the anti-recommended ciphers, rather than copying the current cipher list from Apache.

  Generic test on port 465: works with ECDHE-RSA-AES128-GCM-SHA256

• Dovecot mail delivery agent (IMAP): Ciphers were copied from Apache. Starting in version 2.2.6 it will rebuild DH groups itself on a schedule; we have an earlier version.

  Generic test on port 993: works with DHE-RSA-AES256-GCM-SHA384. It is using prime field DH, not elliptic curves.

• StrongSwan VPN: Cannot replace the DH group, but if it's going to use prime fields it prefers a 2048 bit group if agreed on by the peer, and no Logjam-style proposal downgrade attack is known against IKE.

• OpenVPN: Ciphers were copied from Apache and the custom group file was configured.

  Tested by connecting to the server. I didn't discover which cipher it's actually using.

• OpenLDAP directory server: Ciphers were copied from Apache and the custom group file was configured.

  Generic test on port 636: works with DHE-RSA-AES256-GCM-SHA384. It is using prime field DH, not elliptic curves.

• OpenLDAP directory clients: Ciphers were copied from Apache. Clients use the DH group that the server sends them. Tested and working, but it's hard to determine what cipher it actually used. Sample command line for testing: (substitute your own realm)

  ldapsearch -x -D uid=ldaproot,dc=example,dc=com -y /etc/openldap/root.secret -H ldaps://$HOSTNAME.example.com -LLL -b ou=People,dc=example,dc=com '(uid=jimc)' userPassword

• ldap_nss client: Similarly the ciphers were copied from Apache. Clients use the DH group that the server sends them. Testing is a lot of work; basically I modified my PAM script for common-auth temporarily to rely only on LDAP for authentication, and I was able to get on.

• OpenSSH: The recommended key exchange algorithms were configured, and the DH group (moduli) file is being rebuilt on a schedule.

  ssh -vv says that the key exchange used ecdsa-sha2-nistp256 and the session used aes128-ctr with hmac-md5-etm@openssh.com.

  See this StackExchange question (OP John, 2013-07-29) about junking the MD5 HMACs in the default list. Answerers' consensus was that excess collisions in MD5 do not adversely affect the HMAC in an exploitable way. But I might put on my tinfoil hat and remove them anyway.