Hi, On 05/23/2015 08:47 AM, Willy Tarreau wrote: > Do you have any idea about the ratio of clients (on the net) which don't > support ECDHE right now but support DHE ?
Basically, by totally removing DHE, we would be losing forward secrecy for: - Java <= 6 ; - OpenSSL <= 1.0.0 ; - Android <= 3. Note that moving to a DH size of 2048-bit is an issue if you have Java 6 clients anyway (Java 7 does not support DHE > 1024-bit either, but does support ECDHE). > 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. Ok, moving from Oakley group 2 by default seems to be a smart move anyway. We probably should use this opportunity to move to non-standardized groups for all group sizes. It can't hurt, especially since it took so long to cryptographers to realize that using the Oakley group 2 everywhere was a liability. > 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. Yes, I think it's a good idea. I will post 3 proposals for 1.6 later this week: - a proper fix for the bug found by Hervé Commowick (thanks for the bug report and the testing, by the way) ; - a new configuration option, something like ssl-dh-param-file, allowing the use of a global DH parameters file (which may still be overridden by setting the DH parameters directly in a certificate file) ; - a patch to alter the default DH size from 1024-bit to 2048-bit. I think it may be a good idea to backport the first one to 1.5, and to add one replacing default groups with random, non-standardized ones. I would rather prefer someone from HAProxy generate the new ones, for transparency's sake, but I can help for the process :) I was thinking about what Lukas Tribus said in an other thread, and I agree that the DH configuration is too complicated. Maybe we should try to deprecate the pre-computed DH parameters in 1.6 by issuing a warning whenever they are used, ie then at least one ciphersuite uses a DHE key exchange and no user-specified DH parameters are used (globally or in the certificate file). But as you pointed out, Willy, it means that we cannot fix invalid / weak groups that are stored in files (most probably forever) in the future, so I am not sure what the smartest move is. -- Rémi
signature.asc
Description: OpenPGP digital signature
