Hi Rémi, On Tue, May 26, 2015 at 05:11:36PM +0200, Remi Gacogne wrote: > 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).
Ah good point. Now I remember you explained that to us already in the past. > > 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. Yes I think so as well and that's the issue I'm trying to avoid to re-induce in the future. > > 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) ; Yes, definitely. > - 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) ; Just a question, does it make sense to have different dh-param files per key size so that depending on the cert key size we use a different file, or are they totally decorrelated ? > - a patch to alter the default DH size from 1024-bit to 2048-bit. OK. > 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. Agreed, based on your explanations. > I would rather prefer someone from HAProxy generate the new ones, for > transparency's sake, but I can help for the process :) I can do it if you prefer, after all I'm committing most of the code so if people don't trust me there for the key, I'd urge them to switch to another project because my bugs probably have more impact. And we could go further, by mentionning in the doc how it was generated and how to replace it. > 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. I think that we could reserve the keyword "default" for the dhparam file, or "default-1024", "default-2048", etc... which makes it clear enough about the fact that it's shipped with the product. People who care about security tend to stay away from defaults and can use their own file instead. And those who don't understand anything about this will leave it to the default and trust their distro to ship updated keys if a breach is found. It avoids one level of fallback, as it's the user who decides where the params come from. And it participates in educating users, telling them that DHE doesn't work by itself and that it needs some parameters, which could possibly be weakened and which they should take care of. It also offers a reasonable solution against breaches in well-known dh-params that users could put into their own files (because that's what will happen by copy-paste), as the quick fix for those who don't know how to regenerate that or fear to make thing worse would simply have to replace their file with "default-2048" for example to switch back to something supposedly safe but widely used. Regards, Willy
