I believe that 2048 bit dhparams is too weak. I was the guy who introduced this PR – to make it more secure.
I think we should make this a configuration option that is passed to the ssl template. Let’s open a discussion about how this could be done. 4096 bits is the right way to go about.
If none of this works for the majority – nginx will work fine without dhparams. You can boot discourse, and then generate dhparams while it is running by entering the web container. It’d add a manual step, but you can get your site up and go and grab a cup of coffee or tea while it does its magic.
Anything higher is basically pointless “mine is bigger than yours” wankery:
Similarly, you may also use a 2048-bit modulus, which is already very far into the “cannot break it zone”. The 4096-bit modulus will make DH computations slower (which is not a real problem for a VPN; these occur only at the start of the connection), but won’t actually improve security.
To some extent, a 4096-bit modulus may woo auditors, but auditors are unlikely to be much impressed by a Raspberry-Pi, which is way too cheap anyway.
Indeed, characterising 2048 bit DH parameters as “weak as hell” is quite misleading. There are no known feasible cryptographic attacks against arbitrary strong 2048 bit DH groups. To protect against future disclosure of a session key due to breaking DH, sure, you want your DH parameters to be as long as is practical, but since 1024 bit DH is only just getting feasible, 2048 bits should be OK for most purposes for a while yet.
@codinghorror, I’m sorry I introduced this – I have no issue with it staying the way it is(since the dhparams change I made was rolled back)…I just wanted to open a discussion if having it configurable was useful…I like it configurable with default being 2048 bits.
