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.

Company web sites that are not intended for public consumption should probably not even support any DHE key exchange ciphers.

Unfortunately they are still needed on websites intended for the public, especially if you use social media to share links. The problem is that many of the social media websites (e.g. Tumblr) have utilities that scrape content when a user shares a link (the page title and description is scraped, for example), and those utilities unfortunately often do not support ECDHE key exchange ciphers. Social media is an important component to Internet marketing, so until those resources update their code, we are stuck needing to support the DHE key exchange ciphers.

We can however make sure that DHE key exchange ciphers are only used when the connecting client does not support ECDHE key exchange ciphers.

That does not completely eliminate the exposure to potential DHE specific attacks, but it does reduce it considerably.

For payment processing servers, you should absolutely forbid the use of DHE key exchange ciphers. In fact for payment processing servers, you probably should make a company policy that only ECDSA certificates are allowed so that it is impossible to use 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 the submission Port 587 and the IMAP/POP3 services however it may be possible now to remove support for the DHE key exchange ciphers. I am still investigating the capabilities of mail clients commonly in use.

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.

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

Unless your adversary is the NSA, it probably is safe to use 1024-bit DH parameters as long as they are generated on your server so they are not the same as what is used on thousands of other servers, but why take a chance?

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, and most people who think they do actually do not. But they are there if you want to use them.

Apache Configuration

Apache mod_ssl uses commonly known primes by default for their DH parameters.

Stock Apache uses a 2048-bit group from RFC 3526 by default, but the Apache packaged by LibreLAMP has been patched to use the 3072-bit group by default. This is not because I think the 2048-bit parameters are too weak, but rather, because most Apache servers out there are using the same 2048-bit group I reckoned that group is what a hacker would target if there was a pre-computation attack that worked. Targeting 3072 would be a wast of resources since they would both be much harder to attack and because far fewer servers actually use them.

You probably are safe just letting the mod_ssl package use that RFC 3526 defined 3072-bit group, but if you prefer, you can configure Apache to use one of the custom groups the LibreLAMP packaging of LibreSSL re-generates frequently.

The Almost Right Solution We Can’t Use

Starting with Apache 2.4.8, Apache introduced a new directive called SSLOpenSSLConfCmd that is suppose to allow flexible configuration of OpenSSL parameters. One of those is the configuration of the DH parameters.

Unfortunately that solution requires the SSL_CONF API which was not introduced into OpenSSL until after the LibreSSL fork, and LibreSSL does not implement that API.

This is a feature bug with Apache. Plenty of other server daemons allow easy specification of DH Parameters in a configuration file without needing the SSL_CONF API.

The Wrong Solution We Can Use

Starting with Apache 2.4.7 you can append the DH parameters to the end of the x.509 TLS certificate file. This works but it is conceptually wrong for several reasons:

  1. The TLS certificate is not specific to Apache. It is therefore the wrong place for configuration options that may be specific to Apache. If the same TLS certificate is used with other services, the DH parameters used with Apache may not correspond with what you want used with those other services. This leads to multiple files including the same certificate, increasing the maintenance of the yearly replaced certificate.
  2. Using a certificate file obfuscates the use of custom parameters from other system administrators reading the Apache configuration. Unless they know to look at the certificate files themselves, there is not an indication that custom DH parameters are in use.
  3. Use of custom server-generated DH parameters can not be automated by the packager of the binary Apache package used.

Despite those major flaws, it does work, and is the only option we have available to us.

Scripting The Wrong Solution

The following shell script can be used to automate the process of using custom DH parameters with the Apache web server:


To download: zApacheDHParameters.sh.

I recommend putting the script into /etc/cron.weekly so that it automatically runs once a week:

mv zApacheDHParameters.sh /etc/cron.weekly/
chmod +x /etc/cron.weekly/zApacheDHParameters.sh

The bash array CARR (defined on line 4 of the script) needs to be changed to contain the file name(s) of the certificate(s) that you want the DH parameters appended to. For each virtual host that has an RSA certificate and allows use of the DHE ciphers, you should make sure the first certificate file defined in that virtual host is part of the array.

As written, the script requires that the certificate file(s) live in the /etc/pki/tls/certs directory.

Optionally you can change the script variable BITS (defined on line 6 of the script), but it MUST be a value of 2048, 3072, or 4096 as those are the only values for which LibreLAMP routinely generates new parameters.

You should use a value of at least 2048.

When the script has run, the changes will not not take effect until the next time the Apache web server is restarted. The script will restart Apache if it has been running for at least 10 days. Some places have a scheduled time for non-critical maintenance restarts, if that is the case with your server, then remove the part of the script that restarts Apache.

It is important to note that with dual-certificate virtual hosts that have both an ECDSA and an RSA certificate, the DH parameters are appended to the first certificate defined in the virtual host, regardless of what type of certificate it is.

My Personal Choice

Since most of my servers have migrated to ECDSA certificates where DHE is not even used and since the majority of clients connecting to servers that do support DHE will be using ECDHE anyway, I choose not to worry about it. Apache is patched to use the 3072-bit parameters by default and even though they are a public RFC defined group, I am confident they are secure.

It will not be much longer for me that it is even an issue at all.

Postfix Configuration

Nothing special needs to be done for the Postfix mail server. As packaged by LibreLAMP, by default it will use the 2048-bit parameters generated daily 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 Postfix mail server. As packaged by LibreLAMP, by default it will use the 2048-bit parameters generated daily on your machine without any fuss.

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-20180207
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