Hi Rémi, On Fri, May 22, 2015 at 10:53:08AM +0200, Remi Gacogne wrote: > > >> 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!
Ah OK, thanks! > > 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. Thanks for the detailed explanation, it is very clear now. > However this upgrade will impact the > CPU-load, so a possible, weaker fix is to move to a custom 1024 group. Out of curiosity I just checked and my desktop PC (core2quad 3 GHz) takes 2.9s to generate a new 1024 dhparam, so it could sound acceptable to say that if people want to use 1024 (for performance reasons), we could have to generate it during startup. People running on lower performance machines would be impacted so probably they would just use a fixed larger dhparam, impacting the CPU usage for traffic, but on the other hand when you're using a small CPU you probably don't care much about performance. > 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. Yes absolutely. I'm also thinking that we should support loading the dhparam from a file that every user could generate. This would improve the situation even for those with small CPUs because their startup script could generate this file the first time. FWIW I just tried generating a 2048-bit dhparam, and it took 8mn33 on the machine where the 1024-bit took 2.9s. So probably generating this on the fly upon every startup was a bad idea in the end and doing it once per deployment is better. > 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 :) Sure, but you remember that some people were seriously impacted, reason why I'm still searching the best solution for them. I mean, if their performance is impacted too much, they'll just force dhparam 1024 in the config, resulting in falling back to the well-known, vulnerable one and we want to avoid that. > > 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 Do you have any idea about the ratio of clients (on the net) which don't support ECDHE right now but support DHE ? > - 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. OK that last point is pretty clear and very important because I was wondering if it would be better not to support it at all :-) Then I'd insert a 5th option between 3 and 4 above : use an haproxy-specific version, which becomes a target but has less chances of being targetted if it only represents a small percentage of the traffic and requires a nation- wide grid to pre-compute the values. I mean, this could be an option that would even improve the situation for the stable branches. All users of 1.5 running with dhparam 1024 could use a different one than the known vulnerable one. That would not make them safe, but less likely vulnerable. The doc should be clear about this though. And for future versions we'd support loading it from a file, and emit a warning whenever a pre-computed 1024 is used without being picked from a file. What do you think ? Thanks very much for your explanations. Willy
