[BUG] - wtf no!? Generate DH group ffdhe2048 on the server!

[philipp-intelliroad]

See:

ansible-role-bigbluebutton/tasks/prepare-ssl.yml

Line 48 in 4fc35a3

# TODO: wtf no!? Generate it on the server!

[defnull]

Hmm. Problem is, generating that file takes a really long time to complete. Blocking installs for up to 20 minutes just to generate that file would be really annoying. Generating it only once on the Ansible host would require openssl to be installed and available, which we cannot guarantee.

While generating unique files is of cause more secure, using a pre-generated file in this role is not that bad actually, at least as a fallback. Not so long ago every single Debian server used the same file by default, and ours is twice the size and only shared between a couple of BBB nodes.

I'd propose the following solution:

We add a new config parameter which defaults to ffdhe4096.pem. The role user can change it to point to a different file, which must exist locally on the Ansible host. The role user is responsible for generating that file.

[philipp-intelliroad]

I think the key problem right now and maybe even with your proposed solution is that the user of this role does not know that he/she is using a secret that is shared by multiple installations. I only found out about it while scrolling through the code.

"As generating DH parameters is extremely time consuming, an application should not generate the parameters on the fly but supply the parameters. DH parameters can be reused, as the actual key is newly generated during the negotiation. The risk in reusing DH parameters is that an attacker may specialize on a very often used DH group. Applications should therefore generate their own DH parameters during the installation process using the openssl dhparam(1) application. This application guarantees that "strong" primes are used." See: https://docs.openssl.org/1.1.1/man3/SSL_CTX_set_tmp_dh_callback/#notes

Making the path to the file configurable sounds like a good idea in any case.

[defnull]

the user of this role does not know that he/she is using a secret that is shared by multiple installations.

DH parameters are not a secret. An attacker cannot crack the traffic from a specific TLS server any faster by knowing the DH parameters AFAIK. As the quote says "The risk in reusing DH parameters is that an attacker may specialize on a very often used DH group." If you want to attack thousands or millions of targets at the same time, and you know they all have the same DH parameters, then you can save some time by attacking all at once. There are not enough BBB servers in the world to really gain any real benefits from this, even if all were rolled out with this role. Attacks on BBB, if at all, should usually be targeted and not on a global scale.

So what I am saying: Yes it's best practice to generate those files on each node, but the trade of (20+ minutes extra install time) is not worth it. At least not by default. The group of users that require protection against state-level attacks and still think that BBB is a good idea for that use case, is hopefully quite small.

I still think this should be configurable, for those that want to invest the time.

By the way, you can always execute steps after applying the role. Overwriting the file with your own is just a single ansible task. Maybe two to also reload nginx on a change.

[philipp-intelliroad]

Well the recommenndation reads: "Applications should therefore generate their own DH parameters during the installation process". Here we clearly do not generate a own DH parameter. The least we should do is notify the user about the situation e.g. with a debug/info message.

I totally agree that we can overwrite it later.

In the end I just reposted your TODO from the code here. Please feel free to implement a fix in whatever way you think fits. I have no strong opinion about this ticket.

Thanks for your time and work!

[znerol]

Mozilla suggest to reuse their ffdhe2048.txt file.

Another option would be to simply require TLS 1.3. The ssl_dhparam option only has an effect on older ciphers (DHE-RSA-*). Modern ciphers (ECDHE-*) do not use those params at all. More details in RFC 9325.

That would look something like this.