> OK so now we need to find what to do in the end. From what I understood,
> just removing the lines was a test and is not viable because we'll always
> emit the warning, right ?
Honestly, I'm opting for removing the DH fallback in haproxy altogether and
simple always warn when the certificate (or a dedicated DH file parameter like
nginx does, which was requested earlier this week and makes sense) does not
have the DH parameters.
The fallback we currently have is not very portable (towards openssl forks
I mean - this could be ignored), it has much fragile logic (like trying to
understand
if DHE ciphers are enabled) and with logjam it is now a security problem.
HAproxy should not try (to hard) to fix the security for the user, it should
point
to possible issues via warnings, so that the user can understand and fix them.
Using user generated dhparams is best pratice for TLS setups, unless someone
deliberately disables DHE ciphers I don't see who would not want to do it.
Lets steer our users to a best practices setup instead of code fallbacks.
This proposal could probably be done only in 1.6.
What do you think?
Regards,
Lukas
