Project

General

Profile

Actions

Feature #8869

open

HAproxy should use RFC 7919 DH parameter files

Added by Stéphane Lapie about 6 years ago. Updated about 6 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
haproxy
Target version:
-
Start date:
09/02/2018
Due date:
% Done:

0%

Estimated time:
Plus Target Version:

Description

It would be really nice to have a UI option to generate a custom DH parameter file for HAproxy to use.

The original option is this :

ssl-dh-param-file /dir/file

Actions #1

Updated by Jim Pingle about 6 years ago

  • Subject changed from HAproxy custom DH parameter file to HAproxy should use RFC 7919 DH parameter files

It should not let you use a self-generated DH parameter file, but use the stock system DH parameter files which are from RFC 7919. See #8582

It only appears to specify the length now, instead of pointing to the files pfSense has for the above mentioned DH groups

Actions #2

Updated by Stéphane Lapie about 6 years ago

I understand the intent behind the stock DH parameter files, however some SSL testers raise known DH parameters as something that could be improved. This was my reason for looking into this initially.

As a side-note for future reference if it may help someone, here is what I did on some test pfSense machines :
  • In "Global Advanced pass thru", add this :
    ssl-dh-param-file /etc/haproxy-dh.pem
    
  • Install the pfSense Shellcmd package and register the following command :
    /bin/sh -c "/usr/bin/openssl dhparam -in /etc/haproxy-dh.pem -noout -check || /usr/bin/openssl dhparam -out /etc/haproxy-dh.pem 4096" 
    

This ensures the file is eventually generated (it might take a while, yes), even after restoring the pfSense configuration elsewhere.

Actions #3

Updated by Jim Pingle about 6 years ago

Accommodating SSL testers that have no concept of proper security procedures isn't something we should aspire to do. It doesn't matter if they flag something that is more secure than they expect. If they question it, point them to the RFC that says this is the best practice.

Using custom DH parameters will be less secure, not more. Following bad advice to pass a scan is, well, bad. Don't let them get away with that.

Actions #4

Updated by Stéphane Lapie about 6 years ago

Understood.

I now remember where I had stumbled upon this idea in the first place, it goes back to a few years back when it was found out that some older OS/SSL library/software combinations only had 1024 bits DH parameters, and you had to explicitly have said software load manually generated parameters to work around this.

I now understand that HAproxy is completely unaffected by this because it has its own set of parameter files for whatever size you might require.

Though, in that regard then, the HAproxy documentation stating the following is a bit misguiding :

Custom parameters are known to be more secure and therefore their use is recommended.
Custom DH parameters may be generated by using the OpenSSL command "openssl dhparam <size>", where size should be at least 2048, as 1024-bit DH parameters should not be considered secure anymore.

Sorry for the trouble, and thanks for your patient explanation.

Actions

Also available in: Atom PDF