Hi Lukas,
On Sat, May 23, 2015 at 10:03:01AM +0200, Lukas Tribus wrote:
> > 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.
I'm having a mixed opinion here. We've seen a number of times that many
users don't understand the principle of concatenating dhparams to their
certs, especially those who migrate from other servers or those who don't
know openssl at all. When users have to copy/paste from random blogs some
commands they don't understand, it can result in real security issues,
because they will do whatever they can to shut an error.
However I would find it useful to let the admin provide a file for dhparam
(or files, one per size if that makes sense). That would maintain the ease
of porting certificates without having to modify them. And we could maintain
the pre-computed 2048-bit dhparams so that users don't have to spend 30
minutes generating their own, as Rémi suggests they're quite safe for now.
> 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.
Yes, and what we're really missing is the ability to load from a file to
override these dhparams. When you're a hosting provider and you let your
customers manage their certs, you probably want to have the ability to
load the dhparam from a global file so that in case of trouble with one
dhparam (as with logjam), you regenerate a new one and reload.
> 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.
In my opinion we're not fixing security for the user at all, we're trying
to detect if the user is safe and we warn about what we see. I don't want
to silently fix security for users as it makes them *feel* safe while they
are not necessarily.
> 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.
The problem started to appear when Rémi suggested that 1024 by default was
too small and that we ought to support other sizes, because we didn't want
to break numerous existing setups who didn't provide their own dhparams,
and we didn't want to emit warnings for those who didn't use DHE. That's
what made the logic a bit complex, but it was needed to warn them about
the potential weakness of 1024 (and Rémi was visionary here since nobody
is accidently at risk with logjam without having been warned).
> Lets steer our users to a best practices setup instead of code fallbacks.
I don't see them as code fallbacks, it's just providing the default standard
dhparam groups.
What I think we should do (and could possibly backport to 1.5 if that's not
too intrusive) :
- provide the default standard dhparam groups for each standard size
(2048, more ?)
- optionally let the user load the params from a file
- prefer the cert file's dhparam
For 1024, what we could do :
- in 1.6 : we wouldn't provide one anymore, which means that users could
only load it from a file they would generate if they need one ;
- in 1.5 : we'd regenerate a new one which differs from the fragile one,
just to ensure that haproxy is not targetted at the same time as other
servers. The rationale behind this is that if a nation has the computing
power and storage to precompute all possible values, they'll rather do
it for the group everyone users than the group haproxy 1.5 users only
use.
For 1.6, an alternative could be that we re-compute some groups and put
them into files, or provide the standard ones in files. But that's causing
more moving parts to be deployed and maintained and it could result in the
opposite effect of the desired one : users would store these files in the
config directory, and if one group becomes weak, we couldn't replace it
by delivering a code update, and most users who are not aware of these
issues would never replace their files.
And the problem is already present, because users had to either force 1024
in their config or put a 1024 dhparam into their cert files. All those who
opted for the second option will keep it as-is without ever fixing it, while
the ones who relied on 1024 being forced in the config will automatically
get a different param when they update.
And I'd rather not start to blacklist known fragile dhparams and end up
with a blacklist in the code like openssh does for weak keys...
Best regards,
Willy
