Create/specify appropriate dhparam in Apache/nginx

[jdkasten]

Reminder to create and specify appropriately sized dhparam's for configurations. The default is still 1024.

[kaystrobach]

Generation:

openssl dhparam -out dhparams.pem 2048

Settings for apache 2.4.x

SSLOpenSSLConfCmd DHParameters "{path to dhparams.pem}"

Settings for nginx

ssl_dhparam {path to dhparams.pem}

hints for tomcat / lighthttpd etc. can be found here: https://weakdh.org/sysadmin.html

[lewisgoddard]

I personally generate 4096 bit DHParams, for a little more future proofing. If there is currently a default, I assume that means this is configurable?

[kaystrobach]

according to #489 this seems to be the preferred way :cry:

[jdkasten]

I believe the main issue is that DHparams can take several minutes to generate while the rest of the installation process takes 30 seconds. I haven't really begun researching this problem to try to come up with what I think is a "good solution", but I would like to avoid this process being the bottleneck for the system.

Whether we can avoid configuring straight DH altogether. (Will have to check compatibility issues) ....Or how this long process should be handled.

Any ideas?

[lewisgoddard]

Generating long DH can take up to an hour on some systems, but there is a known attack against 1024 and below.

My only suggestion would be to consider forking out the generation as a side process and notify when complete (somehow). Also, allow the option of specifying a pre-generated DH Parameter file.

[jhalderm]

The only case where I'd urge people to generate their own dh params is if the server defaults to 1024-bit or shorter using shared parameters.

We don't have any reason to think that 2048-bit DL is tractable, even if the parameters are widely shared.

On Mon, Jun 22, 2015 at 3:37 PM, Lewis Goddard notifications@github.com wrote:

Generating long DH can take up to an hour on some systems, but their is a known attack against 1024 and below.

My only suggestion would be to consider forking out the generation as a side process and notify when complete (somehow). Also, allow the option of specifying a pre-generated DH Parameter file.

— Reply to this email directly or view it on GitHub https://github.com/letsencrypt/lets-encrypt-preview/issues/374#issuecomment-114231756 .

[jdkasten]

Thanks, Alex! Pregenerated "Let's Encrypt" DH parameters it is.

[lewisgoddard]

Is there likely to be an option to specify your own parameters file or length?

[schoen]

I have a little bit of information about this in

https://github.com/letsencrypt/lets-encrypt-preview/wiki/Ciphersuite-guidance

I spoke to or found comments from a few experts, including people who worked on the Logjam paper (which includes @jhalderm). So far I have not found anyone who opposes the use of standardized pregenerated DH groups, as long as the size is ≥ 2048 bits (although this is different from the advice to sysadmins on the Logjam site, which does propose creating a custom group).

Daniel Kahn Gillmor, the editor of the new RFC on DH groups, offers a rationale for avoiding custom groups entirely at present, which is found in the citations at

https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-10#section-9.7

[schoen]

@lewisgoddard, there's no reason using the Let's Encrypt client would preclude using custom DH parameters. A good practice might be to make this an external script which runs openssl dhparam and then edits the configuration to make use of the results. If this appears useful to many people, it might be bundled in client packages. As I noted above, I don't see a consensus in favor of doing this by default.

[typingArtist]

How about LE infrastructure help out here by performing a DH param generation with strong primes (4096) continuously, say, one new every hour or so, and providing them as a source for server admins?

LE would be serving a total of more than 8000 different DH primes per year. Admins should be able to choose between (1) DH params from LE, or (2) DH params generated locally. If they choose to get DH params from LE, the script would be provided a set of the last, say, 32 generated params to randomly pick one of them for use.

Another option one could give them is to either (1) do not update DH params ever, (2) automatically fetch/generate new DH params with every new certificate update, (3) automatically fetch/generate new params every n days (including server reload after finished generation).

In case someone chooses to generate DH params locally, I’d add an option for specifying a nice level, where applicable, for ensuring that his server isn’t overloaded with just DH params generation. I don’t think it would make much sense to have the DH param bit length as an option.

[rugk]

Cross-linking to community discussion: Does the LE client also care for the Diffie Hellman keys?

[J0WI]

Shouldn't this be a blocker for 1.0?

[pde]

Whether this is a blocker for 1.0 or not depends on whether the servers we're configuring are willing to use 1024 bit DHE with their 2048+ bit RSA keys. Do we believe that to be the case? If so, it's not just a blocker but an urgent bug.

If not, we can probably close this.

[pde]

(I haven't deep dived on our ciphersuites, but I've assumed that the high marks from SSL Labs mean that we won't negotiate precomputable 1024 bit DH exchanges)

[ian-kelling]

This should be higher priority for nginx.

For debian's nginx package, through stretch, generate a config from a non-ssl config then go to https://www.ssllabs.com/, and you get "This server supports weak Diffie-Hellman (DH) key exchange parameters. Grade capped to B."

[bmw]

This was fixed in Nginx in #4973 and we determined we don't need to do anything special for Apache in the discussion at #4881 because Apache automatically handles this issue.