Hi Remi, This is by far the best write-up on DHE compatibility issues I've seen. Would you mind organizing your research into something we could publish on https://wiki.mozilla.org/Security/Server_Side_TLS ? I've added some notes about compatibility between DHE and Java, but nothing concerning the pre-defined DH groups yet. If you had time to submit it as a pull-request on https://github.com/mozilla/server-side-tls/blob/gh-pages/Server_Side_TLS.mediawiki that would be absolutely fantastic!
Thanks, Julien On Tue 26.May'15 at 17:11:36 +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). > > > 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 >
pgpUN39eilWKn.pgp
Description: PGP signature
