Hi Lukas, On Mon, Jun 01, 2015 at 12:36:13PM +0200, Lukas Tribus wrote: > > I pushed this into 1.6. I'd rather issue -dev2 with it, wait a little bit > > then backport it into 1.5 if we don't get any negative feedback. We might > > have to help distro maintainers prepare some arguments to backport this. > > For the record I checked out current nginx [1] and apache [2] sources and > they don't seem to care about this at all. Nginx has a static 1024bit group > in the source (nothing else) and Apache gets 2048bit+ groups from openssl > (as we did previously).
Great, thanks for checking! > I still think that our approach is suboptimal, mainly because I would > rather not get involved (by introducing a static key) in such advanced > crypto stuff. Sure but if you think about it from a different perspective, it's a reasonable tradeoff between using a well-known param that make it a good candidate for attacks, and having one per clueless user who will never ever change it. And I count myself in the clueless users. If Hervé had not talked to me about logjam, I would have never heard about it. Now I know that I can simply upgrade haproxy to fix the issue. Having to go through a process consisting in carefully editing existing certs just to change a set of params inside is not the thought that motivates me the most in the morning to force me to get up. > A proper solution or proposal should imho come from openssl. They can't > possibly expect application developers to take of such low-level crypto > things. I agree with you, not by laziness but because they provide the stuff that users don't have to understand to remain safe. > At least a recommendation would be nice (get_rfc2409_prime_1024 > is unsafe, don't use it? get_rfc2409_prime_2048 can be considered safe?). Good point. > Anyway, it doesn't look like there the is a simple answer to the question > about whats the right thing to do ... That's how we end up with several solutions, as usual. That makes me think about something I talk about from time to time : to have a diagnostic mode for haproxy, which goes further than warnings, by triggering on many things that might be unintentional but which cannot be fixed in a way to make the warning disappear if intentional. There are examples such as using the same cookie for several servers. And using a 1024-bit key, or even using the oakley group2 typically is such a usecase for the diag mode, where we could alert the user about something suspicious but possibly desired. We could even do it by combining the debug mode with the config check mode. I'm seeing between 2 and 5 levels possible, that might be adjusted using "-d" followed by an optional number : - possibly not secure unless you know what you're doing - suspicious configuration that may be wrong, but you'd rather check - it is not the correct way to do this - it is not the optimal way to do this - configuration could be simplified Here with logjam we have a good candidate for the first level, as we could even imagine detecting oakley group 2 in loaded certs and emitting a warning for them. We could have a "diag()" function working like "Warning()" and calling it, or even simpler, we change the "Warning()" API to pass a level (level 0 being the current one, meaning "this is wrong but I could work around it"). In fact we already have "and I couldn't work around it", so possibly we could shift some warnings already. If someone's interested in working on this, it would be nice. Cheers, Willy
