DH Parameters

Many people do not even know what DH parameters are, or why they are important.

With Ephemeral Diffie-Hellman key exchange, the secure server and the client negotiate a shared secret that allows them to communicate securely.

The DH parameters play a critical role in that process, yet they frequently are not configured properly for optimal security.

This page discusses some of the issues that exist and how to mitigate those issues in the LibreLAMP server environment.

The Logjam Attack

The Logjam attack itself is not a threat to LibreLAMP, LibreSSL simply does not support the Export grade ciphers it attacks. This section is here for the value of the history and what we learned from it.

Political History

During the cold war, before the Internet, cryptography was largely used for military applications. Cryptography was thus classified by the United States under Category XIII of the United States Munitions List.

With the invention of DES encryption in the 1970s, non-military banking started using encryption. With the invention of SSL in the 1990s, encryption was brought to the personal computer using the Internet in the home. It was no longer primarily a military application, but the laws were not updated to reflect that.

Software companies in the United States were required by law to limit the quality of the cryptography in products made for export. This resulted in two different grades of ciphers. The export grade ciphers were limited to a weak 40-bit encryption, while ciphers for non-export products had no limit.

Secure servers in the United States had to support the export ciphers so that clients from outside the United States could connect, and browsers in the United States had to support export ciphers so they could connect to servers outside the United States.

By 2000 those laws had largely been done away with, they were hurting U.S. companies because software companies outside the U.S. could produce cryptography products to meet the growing International demand without restricting the quality of the encryption. However servers and clients continued to support export grade ciphers.

There often is a fear of removing functionality, a fear that some users may still depend upon it. Since clients with better quality ciphers would use those better ciphers when connecting to the server, what harm could there be in leaving the export ciphers enabled on the servers?

As we found out, quite a bit of harm.

The Attack

The year is 2015, it has been about 15 years since the last export browser was released. Yet modern browsers and modern servers still largely support the export grade ciphers. When these ciphers use DHE key exchange, the DH parameters are limited to 512-bit, usually from a small set of common parameters that thousands of servers use.

Researchers discover that the 512-bit DH parameters are so weak, they can easily crack the key exchange and decrypt the encrypted traffic.

That by itself is really only useful when a server is mis-configured to default to the export ciphers, like the tips.fbi.gov website was. Scary that we had (have?) government servers so poorly configured. I have a theory about that, if it is intentionally weak then other agencies can easily get information by eavesdropping without leaving a paper trail that a formal request for information would leave. My tin foil hat is shiny.

However there was another vector. The researchers figured out as long as the server supports export grade ciphers, they could often pull a Man In The Middle attack that tricked the server and client into negotiating the export grade ciphers even when both supported better, resulting in the weaker 512-bit DH parameters being used. This allows the attacker to decrypt the data.

For a more detailed description of the attack, see https://weakdh.org/logjam.html.

This particular implementation of the attack is easy to mitigate on the server by disabling the export ciphers, but we learned a lot from the attack.

DHE Cipher Security

There are several things we learned from the Logjam attack. The most important is probably that when it comes to security, we must be proactive. Leaving old weak ciphers enabled until an exploit is found is the wrong approach to security, we need to constantly evaluate our security and remove what we really no longer need before it can be exploited.

We also learned there are some fundamental flaws with the DHE method of key exchange that need to be taken into consideration:

Avoid DHE Ciphers When Possible

DHE key exchange is an old method of key exchange that has been superseded by ECDHE key exchange.

At this point in time (2019+), web servers should probably not even support any DHE key exchange ciphers.

For mail servers, I personally am a little less clear. SMTP port 25 probably still needs to allow them, I suspect there are a lot of mail servers out there that have not yet upgraded to use TLS libraries that support ECDHE key exchange ciphers. They will try plain text if they can not connect with TLS, so it is better to allow DHE key exchange ciphers and have encryption than to forbid it and have plain text.

For SMTP submission (Port 465 and 587) and the IMAP/POP3 services however it may be possible now to remove support for the DHE key exchange ciphers.

We still at this point in time need to support DHE key exchange ciphers at least for some services, but we should carefully evaluate which services and only support them where removing their support causes real world problems. When supported, they should always come after the better and more efficient ECDHE key exchange cipher suites in the server controlled cipher order. That way they are only used when the client genuinely does not support ECDHE key exchange.

Avoid Common DH Parameters

A large number of web servers use a very small set of DH parameters in common. It was thought this was safe to do, but we learned from the Logjam attack that it is not.

Logjam style attacks require pre-computation based upon the DH parameters that the server uses. When thousands upon thousands of sites use the same parameters, those parameters become a target for pre-computation. Then any site that uses them is vulnerable.

It is best to generate the DH parameters that you will use on the server so that they are not shared in common with thousands of other servers. Re-generate them with some frequency so that by the time anyone does any pre-computations on the DH parameters you are using, they are no longer in use.

Avoid Weak DH Parameters

The Logjam attack could even be pulled off on servers that did not use commonly used 512-bit DH parameters, 512-bit was weak enough that it only took the researchers about a week to make the needed pre-computations for server unique custom 512-bit DH parameters.

The researchers believe that 768-bit DH parameters are within the capabilities of academic research teams to exploit, and that 1024-bit DH parameters may be within the capabilities of state-level attackers.

There is some evidence that the NSA has already done this for the commonly used 1024-bit DH parameters.

When you have to support DHE key exchange at all, make sure to use 2048-bit or stronger DH parameters.

Custom DH Parameters

The LibreSSL package provided by LibreLAMP automatically generates custom DH parameters that can be used by secure servers to protect your TLS traffic from attacks against commonly distributed DH primes. This is a feature of the LibreLAMP packaging, not of LibreSSL itself.

If you have just installed LibreLAMP the custom parameters may not yet have been generated. The custom 2048-bit parameters are generated once a day by the shell script /etc/cron.daily/generate_dh_params.sh and the custom 3072-bit and 4096-bit parameters are generated once a month by the shell script /etc/cron.monthly/generate_dh_params.sh. The results of those scripts are placed in the /etc/pki/tls directory as:

  • /etc/pki/tls/dh2048.pem
  • /etc/pki/tls/dh3072.pem
  • /etc/pki/tls/dh4096.pem

When the LibreLAMP packaging of LibreSSL is first installed, the dh2048.pem, dh3072.pem, and dh4096.pem are initially standard groups from RFC 3526 and were retrieved from https://bettercrypto.org/static/dhparams/. They are quickly replaced by custom generated groups generated on your machine as the cron scripts run.

They will be regularly regenerated, so any server application that uses them will have fresh parameters regularly available, mitigating attack vectors that work by pre-computing results from the existing parameters currently used by the server.

Most servers will need to be periodically restarted to make use of the fresh parameters, but as long as they are generated on your server and thus not commonly used elsewhere, it takes a very long time for an attacker to pre-compute results based on the existing parameters that would be useful in an attack.

LibreSSL also provides the RFC 3526 standard groups from the bettercrypto.org link as:

  • /etc/pki/tls/MODP-IKE-2048-group14.pem
  • /etc/pki/tls/MODP-IKE-3072-group15.pem
  • /etc/pki/tls/MODP-IKE-4096-group16.pem
  • /etc/pki/tls/MODP-IKE-6144-group17.pem
  • /etc/pki/tls/MODP-IKE-8192-group18.pem

It is probably safe to use those instead of what cron generates on your machine if you prefer, especially if you have need for 6144-bit or 8192-bit DH parameters. Most people do not have such a need, and most people who think they do have such a need actually do not. But those groups are there if you want to use them.

Postfix Configuration

Nothing special needs to be done for the Postfix mail server. As packaged by LibreLAMP, by default it will use the 4096-bit parameters generated on your machine without any fuss.

The Postfix directive is named smtpd_tls_dh1024_param_file for historic reasons, the file it points to can be a larger prime parameter.

Please see the LibreLAMP Postfix Configuration documentation for configuring Postfix.

Dovecot Configuration

Nothing special needs to be done for the Dovecot mail server. As packaged by LibreLAMP, by default it will use the 4096-bit parameters generated on your machine without any fuss.

If you use an ECDSA with Dovecot (see the Dovecot TLS Certificate Generation page) then DHE parameters are never used.

Please see the LibreLAMP Dovecot Configuration documentation for configuring Dovecot.

OpenSSH Daemon Configuration

We can not configure the OpenSSH daemon to use the DH parameters generated by the LibreLAMP cron scripts, but we can configure it to prefer ECDHE key exchange, and for clients that do not support ECDHE, to use 2048-bit (and optionally 4096-bit) DH primes generated on the local server.

Edit the file /etc/ssh/sshd_config and add the following:

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

Now generate custom 2048-bit primes and optionally 4096-bit primes:

pushd /etc/ssh
ssh-keygen -G moduli-2048.candidates -b 2048
ssh-keygen -T moduli-2048 -f moduli-2048.candidates
ssh-keygen -G moduli-4096.candidates -b 4096
ssh-keygen -T moduli-4096 -f moduli-4096.candidates

That will take a little while, especially if you choose to generate the 4096-bit primes (couple hours). When it is done:

cp moduli moduli-backup-20210410
cat moduli-2048 moduli-4096 > moduli

Restart the OpenSSH daemon:

systemctl restart sshd.service

How often you regenerate the moduli is up to you, I personally have a cron script regenerate the 2048-bit moduli monthly and the 4096-bit moduli every three months. I almost always connect from an SSH client that supports ECDHE with Curve25519 so for me, the need to generate fresh DH primes for SSH is really just academic.

For a most excellent article on OpenSSH security: https://stribika.github.io/2015/01/04/secure-secure-shell.html