Re: SSL custom dhparam problem
Hi Lukas, On Sun, May 24, 2015 at 12:41:12PM +0200, Lukas Tribus wrote: > > 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 ; > > You are implying that we will provide 2048 bit dhparams, correct? Yes I still think it has some benefits given *where* admins store their files (ie: this dhparam is in the config part, it will not be updated and they're not aware of vulnerabilities requiring an update). I'm not seeing any other easy way to *distribute* fixes. Keep in mind that most users simply use their distro's (auto-)update mechanism to stay up to date and will never even know that a dhparam file lying in their config directory *needs* to be regenerated. > > 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... > > Its unlikely that we will know when 2048 bit dhparams are broken, Sure, but when we know it we can force an update on users via the regular update channels (eg: distro updates). Those relying on their own file are expected to know what to do. > therefor > the best long-term solution imho would be to not include any pre-computed > groups at all. That's where I disagree from a distribution perspective. > Also, I'm not sure if a code upgrade to deal with a compromised dhparam group > is an efficient way to push a new group out there. We would have to see this > as security issue and assign CVE candidates to make package maintainers even > consider a backport. But that's already how any SSL fix is deployed and I tend to consider that it works reasonably well, simply because users don't have to care about anything, they let their system update itself. If any SSL fix would require a change to openssl.cnf instead of the code, you can bet it would remain bogus for a much longer duration in field. > As with many of the SSL/TLS problems lately, the admin needs to understand > and configure the server according to best pratices. I think we should push > in that direction, even if usability suffers a tiny little bit. The problem is that SSL/TLS *is* complex and that most users are not cryptography experts and do not understand a single concept of what is behind with all those acronyms and numbers. For most people, 1024 is better than 256 and that's all. From what I've read, an ECDSA-256 key provides as good a protection as RSA with about 3kbit. Still, for most readers, RSA-1024 will be 4 times better than ECDSA-256. So we cannot just rely on the admin becoming skilled in this obscure area, we need to help them stay safe to avoid the worst mistakes. Also, lack of usability is always what leads to seek for help and pick of the wrong solution for most users. My point of view has always been that people who know must have the final choice so we need a lot of configurability. But those who don't know would better be correctly protected than poorly because they copy-pasted something that was not made for them and that results in their config to appear as valid. > For the record, I don't think: > openssl dhparam 2048>dhparamfile > #grep dh-param-file /etc/haproxy.cfg > tune.ssl.dh-param-file dhparamfile > > is hard do document, understand and configure at all. I know a number of environments where it is difficult to find the openssl utility, and even worse in the correct version! I'm not kidding! Let alone that it can take half an hour, you know what will happen ? While it's running and displaying dots, a number of users will press Ctrl-C, type the same command on google, find that it is normal that it can take that much time (even more than they have available), and will lazily copy-paste the output of the command they found on the page without knowing if there's any risk in doing that (eg: I've read that if they're created with -dsaparam, they're weaker and subject to sub-group attacks). And it's easy to find such examples : https://github.com/opnsense/core/blob/master/src/etc/dh-parameters.2048 https://github.com/endor/cob
RE: SSL custom dhparam problem
>> 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. Which is why I would opt for simple and well-documented behavior in haproxy. Currently its not particularly straightforward: http://marc.info/?l=haproxy&m=143228478812983&w=2 When we have an dedicated option to point to a dhparam file, like nginx does, its simple and easy to document. No need for the user to google around. > 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. Yes, that is definitly something we need to do, either way. > 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 ; You are implying that we will provide 2048 bit dhparams, correct? > - 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. Sure, we can't break 1.5 setups now. > 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... Its unlikely that we will know when 2048 bit dhparams are broken, therefor the best long-term solution imho would be to not include any pre-computed groups at all. Also, I'm not sure if a code upgrade to deal with a compromised dhparam group is an efficient way to push a new group out there. We would have to see this as security issue and assign CVE candidates to make package maintainers even consider a backport. As with many of the SSL/TLS problems lately, the admin needs to understand and configure the server according to best pratices. I think we should push in that direction, even if usability suffers a tiny little bit. For the record, I don't think: openssl dhparam 2048>dhparamfile #grep dh-param-file /etc/haproxy.cfg tune.ssl.dh-param-file dhparamfile is hard do document, understand and configure at all. Its an additional task the admin needs to do, thats correct. But in the long run its the better thing to do. Btw SSLLabs already provides a test to check for "common DH prime" numbers. Just my two cents. Regards, Lukas
Re: SSL custom dhparam problem
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
RE: SSL custom dhparam problem
> 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
Re: Re: SSL custom dhparam problem
On Fri, May 22, 2015 at 10:58:47AM +0200, Remi Gacogne wrote: > > > On Fri, May 22, 2015 at 09:10:36AM +0200, Hervé Commowick wrote: > >> As a temporary solution, i have decided to use a custom DH param for each > >> bind, but anyway, this clearly need a fix :) > > > > Did you test Rémi's patch to confirm the origin of the issue ? > > It would be great if Hervé could confirm that the patch fix his issue. I > can reproduce it without the patch, and not with it. 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 ? Thanks, Willy
Re: Re: SSL custom dhparam problem
> On Fri, May 22, 2015 at 09:10:36AM +0200, Hervé Commowick wrote: >> As a temporary solution, i have decided to use a custom DH param for each >> bind, but anyway, this clearly need a fix :) > > Did you test Rémi's patch to confirm the origin of the issue ? It would be great if Hervé could confirm that the patch fix his issue. I can reproduce it without the patch, and not with it. -- Rémi signature.asc Description: OpenPGP digital signature
Re: SSL custom dhparam problem
diff --git a/src/ssl_sock.c b/src/ssl_sock.c index d0f4d01..c5bd2f9 100644 --- a/src/ssl_sock.c +++ b/src/ssl_sock.c @@ -1076,10 +1076,6 @@ int ssl_sock_load_dh_params(SSL_CTX *ctx, const char *file) if (dh) { ret = 1; SSL_CTX_set_tmp_dh(ctx, dh); - /* Setting ssl default dh param to the size of the static DH params - found in the file. This way we know that there is no use - complaining later about ssl-default-dh-param not being set. */ - global.tune.ssl_default_dh_param = DH_size(dh) * 8; } else { /* Clear openssl global errors stack */ On Fri, May 22, 2015 at 10:50 AM, Hervé Commowick wrote: > Hey Willy, > > > I confirm his patch work as expected, it just need to be modified a bit to > apply on 1.5, but not a big deal. > > Hervé. > > On Fri, May 22, 2015 at 10:28 AM, Willy Tarreau wrote: > >> Hi Hervé, >> >> On Fri, May 22, 2015 at 09:10:36AM +0200, Hervé Commowick wrote: >> > As a temporary solution, i have decided to use a custom DH param for >> each >> > bind, but anyway, this clearly need a fix :) >> >> Did you test Rémi's patch to confirm the origin of the issue ? >> >> I think it should probably be fixed before we issue 1.5.13, so we need >> to decide quickly what has to be done. >> >> Willy >> >> >
Re: SSL custom dhparam problem
Hey Willy, I confirm his patch work as expected, it just need to be modified a bit to apply on 1.5, but not a big deal. Hervé. On Fri, May 22, 2015 at 10:28 AM, Willy Tarreau wrote: > Hi Hervé, > > On Fri, May 22, 2015 at 09:10:36AM +0200, Hervé Commowick wrote: > > As a temporary solution, i have decided to use a custom DH param for each > > bind, but anyway, this clearly need a fix :) > > Did you test Rémi's patch to confirm the origin of the issue ? > > I think it should probably be fixed before we issue 1.5.13, so we need > to decide quickly what has to be done. > > Willy > >
Re: SSL custom dhparam problem
Hi Hervé, On Fri, May 22, 2015 at 09:10:36AM +0200, Hervé Commowick wrote: > As a temporary solution, i have decided to use a custom DH param for each > bind, but anyway, this clearly need a fix :) Did you test Rémi's patch to confirm the origin of the issue ? I think it should probably be fixed before we issue 1.5.13, so we need to decide quickly what has to be done. Willy
Re: SSL custom dhparam problem
As a temporary solution, i have decided to use a custom DH param for each bind, but anyway, this clearly need a fix :) Hervé. On Fri, May 22, 2015 at 6:14 AM, Willy Tarreau wrote: > Hi Rémi, > > On Thu, May 21, 2015 at 11:19:15PM +0200, Remi Gacogne wrote: > > > > Hi Hervé, > > > > On 05/21/2015 10:11 PM, Hervé Commowick wrote: > > > > > I encounter a problem with dhparam configuration, if i have 2 bind > lines, a > > > tune.ssl.default-dh-param 2048, and a custom group dhparam in one of > the > > > pem file, ALL bind lines will use 1024, the one with the custom group > will > > > work as expected, and the one without will use the default Oakley > group 2 > > > instead of the 2048-bit MODP group 14 (thx Remi for the wording, i'm > not > > > sure to well understand all of that :)) > > > > > > this is clearly a bug amha, thx anyone who can help (Remi ? :) ) > > > > Oh, this is a bug indeed, and it's my fault. In order to prevent the > > display of warning messages about default-dh-param not being set when a > > static DH group value is used, the value of default-dh-param is > > overridden when a static DH group value is found. It does work when you > > have only one bind, but it's clearly wrong when more than one is used, > > like in your configuration. > > > > Could you try with the attached patch? It's a patch against the 1.6 > > trunk but it does apply cleanly against 1.5.12. > > > > It will result in false positive messages about default-dh-param not > > being set when it's not needed, but to prevent that we will need to > > check if each bind has a static DH group value, which I'm not very fond > of. > > I think we could proceed differently then : if no global dhparam is set > when parsing the bind line *and* no dhparam is set in the file, then we > should set it and emit the warning at this moment. Or alternatively, > we could even just set the global param from the bind line when it was > not set. > > Willy > >
Re: SSL custom dhparam problem
Hi Rémi, On Thu, May 21, 2015 at 11:19:15PM +0200, Remi Gacogne wrote: > > Hi Hervé, > > On 05/21/2015 10:11 PM, Hervé Commowick wrote: > > > I encounter a problem with dhparam configuration, if i have 2 bind lines, a > > tune.ssl.default-dh-param 2048, and a custom group dhparam in one of the > > pem file, ALL bind lines will use 1024, the one with the custom group will > > work as expected, and the one without will use the default Oakley group 2 > > instead of the 2048-bit MODP group 14 (thx Remi for the wording, i'm not > > sure to well understand all of that :)) > > > > this is clearly a bug amha, thx anyone who can help (Remi ? :) ) > > Oh, this is a bug indeed, and it's my fault. In order to prevent the > display of warning messages about default-dh-param not being set when a > static DH group value is used, the value of default-dh-param is > overridden when a static DH group value is found. It does work when you > have only one bind, but it's clearly wrong when more than one is used, > like in your configuration. > > Could you try with the attached patch? It's a patch against the 1.6 > trunk but it does apply cleanly against 1.5.12. > > It will result in false positive messages about default-dh-param not > being set when it's not needed, but to prevent that we will need to > check if each bind has a static DH group value, which I'm not very fond of. I think we could proceed differently then : if no global dhparam is set when parsing the bind line *and* no dhparam is set in the file, then we should set it and emit the warning at this moment. Or alternatively, we could even just set the global param from the bind line when it was not set. Willy
Re: SSL custom dhparam problem
Hi Hervé, On 05/21/2015 10:11 PM, Hervé Commowick wrote: > I encounter a problem with dhparam configuration, if i have 2 bind lines, a > tune.ssl.default-dh-param 2048, and a custom group dhparam in one of the > pem file, ALL bind lines will use 1024, the one with the custom group will > work as expected, and the one without will use the default Oakley group 2 > instead of the 2048-bit MODP group 14 (thx Remi for the wording, i'm not > sure to well understand all of that :)) > > this is clearly a bug amha, thx anyone who can help (Remi ? :) ) Oh, this is a bug indeed, and it's my fault. In order to prevent the display of warning messages about default-dh-param not being set when a static DH group value is used, the value of default-dh-param is overridden when a static DH group value is found. It does work when you have only one bind, but it's clearly wrong when more than one is used, like in your configuration. Could you try with the attached patch? It's a patch against the 1.6 trunk but it does apply cleanly against 1.5.12. It will result in false positive messages about default-dh-param not being set when it's not needed, but to prevent that we will need to check if each bind has a static DH group value, which I'm not very fond of. -- Rémi diff --git a/src/ssl_sock.c b/src/ssl_sock.c index 9302869..5317a28 100644 --- a/src/ssl_sock.c +++ b/src/ssl_sock.c @@ -1347,10 +1347,6 @@ int ssl_sock_load_dh_params(SSL_CTX *ctx, const char *file) if (dh) { ret = 1; SSL_CTX_set_tmp_dh(ctx, dh); - /* Setting ssl default dh param to the size of the static DH params - found in the file. This way we know that there is no use - complaining later about ssl-default-dh-param not being set. */ - global.tune.ssl_default_dh_param = DH_size(dh) * 8; } else { /* Clear openssl global errors stack */ signature.asc Description: OpenPGP digital signature
SSL custom dhparam problem
Hello, I encounter a problem with dhparam configuration, if i have 2 bind lines, a tune.ssl.default-dh-param 2048, and a custom group dhparam in one of the pem file, ALL bind lines will use 1024, the one with the custom group will work as expected, and the one without will use the default Oakley group 2 instead of the 2048-bit MODP group 14 (thx Remi for the wording, i'm not sure to well understand all of that :)) here is a test config which will fail for 1.1.1.2:443 : global ssl-default-bind-ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA ssl-default-bind-options no-sslv3 tune.ssl.default-dh-param 2048 tune.ssl.maxrecord 1419 tune.ssl.cachesize 5 tune.ssl.lifetime 600 frontend foo bind 1.1.1.1:443 ssl crt certs_with_static_1024_dhparam.pem bind 1.1.1.2:443 ssl crt cert_without_static_dhparam.pem this is clearly a bug amha, thx anyone who can help (Remi ? :) ) Hervé C.