>> Otherwise it makes no sense, sorry about that. > > ah ? Well, with the previous command I was basically saying "if a DH 2048-bit group is too much CPU-consuming for you, just use a 2048-bit group", which makes no sense at all!
> I think you have to realize that I don't understand anything at all > here, I have no idea with an "Oakley group 2" is. I'm just a regular > user when it comes to SSL. Is it the thing that is assigned by default > when using "default-dh-param" ? Ah, I really have to find the time to write a better documentation for this! When you use the openssl dhparam command, it generates a custom, random DH group (more or less a set of possible values) of the specified size. If this group is added to the certificate file, Haproxy will use it for DHE key exchanges for all binds using that certificate file, no matter what the value of default-dh-param is. If you don't set a custom DH group in the certificate file, Haproxy will use one of the pre-configured ones based on the MIN(default-dh-param, certificate key size): - Oakley group 2 for 1024-bit - MODP group 14 for 2048-bit - MODP group 16 for 4096-bit - MODP group 18 for 8192-bit These groups are fine, they work correctly, but it may be possible to pre-compute all the possible values in a given DH group <= 1024. The most used group on the internet is the "Oakley group 2", because it was standardized in rfc2409, and therefore it is now advised not to use it. The best fix is simply to move to a larger group, containing so much more values that pre-computation seems out of reach for the time being. This can be done by setting default-dh-param to 2048, or by using a custom group of size 2048. However this upgrade will impact the CPU-load, so a possible, weaker fix is to move to a custom 1024 group. Because this custom group is randomly generated by openssl dhparam, you are probably the only one using it, so there is a lot less benefit for an adversary to try to pre-compute this group. And it is very likely not possible to pre-compute every possible group at this time. Note that we could move to another default 1024-bit group in haproxy, but as long as we ship one, it becomes a valuable target because it will be used by a lot of people, so I believe the correct fix is to move to a 2048-bit group by default, as you suggested in another thread :) > In this case, does it mean that generating a random dh-param at boot > would solve the issue ? Yes, or even only once. The basic idea is: - use ECDHE instead of DHE if you can, but not all clients support that - failing that, use a large DH group, a least 2048-bit - failing that, use a group you generated yourself randomly, so that not everybody is using the same - failing that, it is better to use the Oakley group 2 than no DHE at all. -- Rémi
signature.asc
Description: OpenPGP digital signature
