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 2048dhparamfile #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/cobot_captive_portal/blob/master/etc/dh-parameters.2048
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=haproxym=143228478812983w=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 2048dhparamfile #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: 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: 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: 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 her...@gmail.com 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 w...@1wt.eu 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 w...@1wt.eu 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
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.
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
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
