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


Reply via email to