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