c9111e

The Logjam attack

The Logjam attack is based on a weakness found in the Diffie-Hellman (DH) key exchange method. By using Logjam, an attacker can force an otherwise secure connection to be downgraded to a vulnerable one, which they can easily break.

Fortunately, there are a few ways we can mitigate against this attack.

General guidance

Firstly, you should disable “export” ciphers. Most browsers don’t use these any more, as they’re known to be vulnerable. The attack relies on these weak ciphers being available, so if they’re disabled, the attack fails. While changing your available cipher suites to exclude export ciphers, consider looking at moving to a modern configuration.

Without going into the maths, DH is based on the exchange of large prime numbers. The larger the number, the harder the encryption is to break. Currently, numbers larger than 1028 bits are considered safe. If you make sure to use only numbers of 2048 bit or higher, the attack should fail.

Plesk 12.5+

Plesk 12.5 and higher provide a single script to manage encryption, server-wide. To ensure you’re using the encryption settings recommended by Plesk, run following command:

   plesk sbin pci_compliance_resolver --enable

Alternatively, if you wish to address the Logjam attack only without changing other settings:

   plesk sbin sslmng --strong-dh

Generating new Strong DH groups on with OpenSSL

To generate a new set of prime numbers for DH to use, run the following command. Please note that generating large prime numbers is a fairly intensive task, so where possible avoid running this on a live server already under high load:

openssl dhparam -out dhparams.pem 2048

Apache

The parameters to change are:

SSLCipherSuite At least add :!EXPORT, if possible use a modern configuration.
SSLHonorCipherOrder on      

Nginx

The parameters to change are:

ssl_ciphers At least add :!EXPORT, if possible use a modern configuration.
ssl_prefer_server_ciphers on;
ssl_dhparam /path/to/dhparams.pem;

OpenSSH

Add KexAlgorithms to sshd_config to avoid algorithms that use DH key exchange with weak keys:

KexAlgorithms curve25519-sha256@libssh.org, diffie-hellman-group-exchange-sha256

Change the existing moduli so 1024 bit keys are not available: Remove all DH moduli < 2048

awk '$5 > 2000' /etc/ssh/moduli > ~/moduli

Check new file looks OK, and doesn’t have any 1024 bit keys, then if it’s good, copy it into place:

mv ~/moduli" /etc/ssh/moduli

Or generate new ones from scratch. This is more computationally expensive, but gives you all new keys:

ssh-keygen -G moduli.candidates -b 2048 (or 4096 if you're paranoid)
ssh-keygen -T moduli.safe -f moduli.candidates
mv moduli.safe /etc/ssh/moduli

Testing

There are external web-based testers such as this one from KeyCDN.com.

Warning

UKFast is not responsible for the performance of 3rd party software or testing tools.