9

Does it increase connection security if I regenerate the dhparam files used with NGINX on our servers periodically e.g. every week?

What issues may arise from this?

Is there any benefit in doing this?

Flatron
  • 225
  • 1
  • 6
  • The big bad boys aren't likely to be deterred just by a new DH param set. – Deer Hunter Mar 04 '16 at 08:11
  • I also hope you ain't doing it on production machines. – Deer Hunter Mar 04 '16 at 08:12
  • @DeerHunter that's exactly why I am asking this question, does it make sense to run such things on a productive system? Ofc the "bad boys" won't care much but does it make it anything generally more secure? – Flatron Mar 04 '16 at 09:06

1 Answers1

11

Does it increase connection security if I regenerate the dhparam files used with NGINX on our servers periodically e.g. every week?

No, not significantly.
DH parameters are really just a large prime that takes a lot of time to be generated (because it needs to be a safe prime). Additionally there's a so-called "generator", but this one is cheap to generate.
Right now it is impossible to break a DH connection negotiated with a 2048-bit or longer safe prime. Thus if you regenerate your safe prime every week you gain no extra security beyong "unbreakable". However this should not be confused with generating your own proper (strong) parameters once. This is to make an internet-scale Logjam attack much more difficult, but as I already said is optional as the parameters can't be broken anyways.

What issues may arise from this?

More computational load. Generating the parameters is probably one of the most intense cryptographic computations you will encounter.

Is there any benefit in doing this?

You gain something like "super-forward-secrecy". With ephemeral Diffie-Hellman, the attacker needs to break each connection individually to recover plaintexts. The per-connection load can be reduced when applying the Logjam trick of doing one giant pre-computation for the parameters and only doing the last step for each connection. If you change your parameters regularly you limit the impact a Logjam-style attack could have. However, running the algorithm required for Logjam is infeasible for DH parameters that use long primes (e.g. 2048-bit or more) .

SEJPM
  • 9,540
  • 6
  • 37
  • 67
  • I agree with most of this answer, although I fail to see how a TLS server could avoid sending DH parameters either as part of ServerKeyExchange or within its certificate if a DH certificate is used, when establishing a new session. – Erwan Legrand Mar 04 '16 at 12:46
  • @ErwanLegrand, theoretically you could somehow (OID) encode a name for a set of DH parameters. But this is only a thing for ECC apparently :/ Updated the answer accordingly. – SEJPM Mar 04 '16 at 12:53
  • 1
    (1) FFDH isn't required to be a safe prime, only to have a subgroup with nonsmooth order; using a safe prime is _one_ simple way to do this. Schnorr primes kq+1 like for DSA are also satisfactory and generate faster; in OpenSSL (typically used with nginx) see man for `openssl dhparam -dsaparam`. (2) In 2018 (2 years later) TLS1.3 _does_ encode both ECDHE curves (now limited to P-256 P-384 P-521 X25519 X448) and FFDHE groups from rfc7919 (similar to, but different from, Oakley groups used for IPsec and some SSH). Cheer. – dave_thompson_085 Nov 24 '22 at 16:02