2048 bit Diffie-Hellman Params are too weak


(Robby O'Connor) #1

Continuing the discussion from

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.


(Sam Saffron) #2

I am not following, cause I do not think the config will boot if you point it at a file that does not exist. Can you confirm this?


(Robby O'Connor) #3

Diffie-Hellman params aren’t necessarily required…lemme verify


(Sam Saffron) #4

My point is that this line:

Will stop NGINX from booting if /shared/ssl/dhparams.pem; is missing in action.


(Robby O'Connor) #5

Oh right that will cause an issue…maybe add the option to generate stronger dhparams…adding a warning that 4096 bit dhparams will take a bit…


(Sam Saffron) #6

I am fine to make this a param, and just default it to 2048.


(Robby O'Connor) #7

yeah – maybe also mention it’s weak as hell.


(Sam Saffron) #8

I am deferring to @mpalmer here who knows SSL about 100 times better than me :), but please give us some time here we are mostly on holidays.


(Jeff Atwood) #9

The premise is incorrect: 2048 is quite strong.

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.


(Matt Palmer) #10

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.


(Robby O'Connor) #11

Making it configurable is a middle-ground…I mean I’m also fine with leaving it as-is – I can always regenerate them on my own…


(Jeff Atwood) #12

Bear in mind that every additional bit doubles the attack space. So adding 1024 bits to 1024… is quite a lot already.


(Martial) #13

Remind me this :


(Robby O'Connor) #14

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


(Robby O'Connor) #15

:joy: :joy: :joy: :joy: :joy:


(Richard - DiscourseHosting.com) #16

There is nothing secret about those DH parameters.
So if you trust these guys, you can just download the latest dhparam file here, no need to calculate them yourself.

It’s just a wget in your install script.