Using predefined Finite field groups for DHE. (rfc7919)

[RoelSG]

---

Desired Behavior

100% Compliance on internet.nl

Current Behavior

I thought it was time again to make sure my webserver's security is up-to-snuff, so I checked it at a few sites. SLL-labs seems fine, A+, but internet.nl just implemented new guidelines from the Dutch government and has three (actually two) remarks.

• Your web server supports 0-RTT, which is not secure.
  Okay, seems easy enough to turn off, but it supposedly comes with a latency penalty. Also unclear how "unsecure" this really is.
  I think it's the following line in ssl.conf:

# Enable TLS 1.3 early data
ssl_early_data on;

Edit: Found an older blog entry about 0-RTT https://blog.trailofbits.com/2019/03/25/what-application-developers-need-to-know-about-tls-early-data-0rtt/ which explains some of the problems with it. Is this a sane default for SWAG? It is meant as a reverse proxy for almost anything, which in turn might not implement their own protection.

• Your web server does not enforce its own cipher preference
  It ignores this one if you only support "good ciphers", which I do, except:
• Your web server supports insufficiently secure parameters for Diffie-Hellman key exchange. We test if your DHE public key material uses one of the predefined finite field groups that are specified in RFC 7919. Self-generated groups are 'Insufficient'.

Per the SWAG docs:
The container provides a pre-generated 4096-bit dhparams.pem (rotated weekly via Jenkins job) for new instances, however you may generate your own by running docker exec swag openssl dhparam -out /config/nginx/dhparams.pem 4096 WARNING: This takes a very long time

Not sure I totally agree with the score, length-wise the key is totally fine, but Mozilla also seems to agree that you should use predefined Finite field groups for DHE.

Explanation from the Dutch NCSC Guidelines:

The complexity associated with free choice of finite field groups has been a source of vulnerabilities in the past. The TLS 1.3 specification only includes a limited number of finite field groups for DHE to reduce this complexity. These guidelines limit Sufficient groups for TLS to those used in TLS 1.3 (and specified in RFC 7919).
ffdhe4096 (RFC 7919) Sufficient
39ffdhe3072 (RFC 7919) Sufficient
ffdhe2048 (RFC 7919) Phase out
Other groups Insufficient

These guidelines advise the use of standardized groups. Larger groups are chosen to mitigate against the risk of precomputation by attackers. This conservative approach enlarges the performance penalty that comes with the use of DHE. Carefully evaluate and use ECDHE instead of DHE if you can.

Alternatives Considered

Changing the .pem in ssl.conf:

# Diffie-Hellman parameter for DHE cipher suites
ssl_dhparam /config/nginx/dhparams.pem;

To a predefined one:

ffdhe4096 (RFC 7919)
sha256 checksum: 64852d6890ff9e62eecd1ee89c72af9af244dfef5b853bcedea3dfd7aade22b3

ffdhe3072 (RFC 7919)
sha256 checksum: c410cc9c4fd85d2c109f7ebe5930ca5304a52927c0ebcb1a11c5cf6b2386bbab

Or,
Removing DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384; from ssl.conf
This works at least, but removes support for some older clients. It also makes the pre-generated 4096-bit dhparams.pem redundant.

[github-actions]

Thanks for opening your first issue here! Be sure to follow the bug or feature issue templates!

[aptalca]

I've been reading about this and there are some confusing points (also, I'm very far from being a crypto expert).

First of all, I get that 1024 bit DH groups are not considered secure, because many are vulnerable to precomputation and that a large fraction of Internet communication depended on a few small, widely shared groups.

What I don't get is, given the problem was due to many servers using the same widely shared groups, how come the recommendation is for everyone to use the same widely shared group (ffdhe4096)? Shouldn't we want everyone to use different random generated groups to reduce the attack surface?

I read comments about how many servers in production use groups that were not properly generated, and that many clients don't do any confirmations and just rely on the server provided groups. I get those. But aren't they mitigated as long as the server generates the groups properly? So it would be an issue from the client's perspective where they can't make sure that the group is properly generated, but that's not my concern (as the server admin).

We use the latest openssl and do openssl dhparam -out /dhparams.pem 4096, which is the recommended safe method per https://weakdh.org/sysadmin.html and we rotate the groups weekly to ensure our users don't all use the same groups.

I just have not been able to see any well made point showing how everyone using the same predefined group is indeed better than a server properly and randomly generating a 4096 bit group from the server admin's point of view.

[RoelSG]

Looks like the most used reason is interoperability.
Lets use specific groups so everyone uses the same parameters, and audit those specific ones to make sure they are still safe. Government likes that they are audited, so they recommend them (probably). I agree with you that its a weak rationale, though its also Mozilla that recommends it.
What about commenting out ssl_early_data on; as a secure default? I do think the rationale behind that is a bit better if exposing the proxy to the internet.

[aptalca]

It sounds like replay attacks are possible even without 0-RTT: https://vnhacker.blogspot.com/2015/12/bad-life-advice-never-give-up-replay.html
We always have to maintain a balance between security and convenience. The only thing that is totally secure is something that has no input or output and is completely sandboxed (hypothetical scenario).

In this case, I'd say the replay attack prevention burden should be on the app itself. Any app with such crucial operations should be using a token based system or something like that to prevent such issues. Otherwise, someone else replaying your transmission should be no different than your browser or client resubmitting the data (which already happens in various cases due to glitches or connection issues). The other user won't be able to hijack your connection as they won't be able to decrypt the response sent back, only duplicate the original transmission. It's like when websites tell you not to refresh the page while they're sending credit card info for payment over the internet to prevent getting double charged. In reality, any sane backend will reject duplicate requests.

[RoelSG]

Makes sense, Im mostly reporting the changes the site made to its scoring (it really doesn't like heimdall.site by the way), and seeing what you guys think. The finite field groups is a tricky one, and I'm unsure what is better there. I just turned these ciphers off DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;.
As for 0-RTT; because we don't know what app the user puts behind the proxy, 0-RTT off seems a more secure default, until needed or wanted.

[aptalca]

I mean, all of that is user configurable. We just ship a set of defaults that maintain a balance between security and convenience and should work for most users without tinkering (closely follows Mozilla intermediate recommendations and gets an A+ on ssllabs). But as the admin of your server, you have full control over all of that simply by editing the files under /config.

Some headers even are included but commented out, so you can decide whether to enable or not (including HSTS).

So you can go ahead and replace the dhparams file with the RFC7919 one, and comment out the ssl early data. Restart the container and voila.

[RoelSG]

Oh yeah I did that already, I just figured I should inform you guys at least. the NCSC made these guidelines for a reason. The fact that only these "minor" points are mentioned show that it's already really good by default.
You can close the issue if this is enough.

[nemchik]

I would be open to including Mozilla's modern cipher configuration as a commented line with instructions for swapping out the default line we include (which is Mozilla's intermediate configuration).

Edit: I like the rest of the defaults we have, but if there's proven security issues I'm open to adjusting.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[aptalca]

#115