FREAK/Logjam, and SSL protocols to use
List, good afternoon,
I was reading up on a TLS Diffie Hellman protocol weakness described here
https://weakdh.org/sysadmin.html
which is similar to the earlier FREAK attack, and can result in downgrade of cipher suites.
Part of the solution workaround that the researchers describe for Dovecot here
https://weakdh.org/sysadmin.html
includes altering DH parameters length to 2048, and re-specifying the allowable cipher suites - they give their suggestion.
But the researchers make no comment on the allowable protocols that, in Dovecot, are controlled in 10-ssl.conf in the stanza headed
# SSL protocols to use #ssl_protocols = !SSLv2
I couldn't find any advice on up-to-date SSL/TLS protocol settings in the Dovecot wiki, either (I looked in http://wiki2.dovecot.org/SSL/DovecotConfiguration ).
At the moment our installation is using only the default settings for allowed protocols; I'm not sure what those defaults might be, but our 10-ssl.conf may only be disallowing SSLv2, if the 'example' entry is the default. We're running 2.2.15, and are due to upgrade to 2.2.18 shortly; quite possibly the defaults differ in a more recent release.
What SSL protocols do folk on the list recommend should be allowed in Dovecot these days? (Actually, I mean which protocols really 'must' be disallowed?)
regards, Ron
On 26/05/2015 15:37, Ron Leach wrote:
I was reading up on a TLS Diffie Hellman protocol weakness described here
Sorry, wrong link. The weakness is described at the front page here
The page with the Dovecot advice was correct:
regards, Ron
Am 26.05.2015 um 16:37 schrieb Ron Leach:
# SSL protocols to use #ssl_protocols = !SSLv2
you should use
ssl_protocols = !SSLv2
you may use
ssl_protocols = !SSLv2 !SSLv3
if you havent any clients that can only work on SSLv3 i.e outdated Netscape etc
Best Regards MfG Robert Schetterer
-- [*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
On Tue, May 26, 2015 at 03:37:39PM +0100, Ron Leach wrote:
What SSL protocols do folk on the list recommend should be allowed in Dovecot these days? (Actually, I mean which protocols really 'must' be disallowed?)
I use this: ssl_protocols = !SSLv2 !SSLv3 ssl_cipher_list = ECDH@STRENGTH:DH@STRENGTH:HIGH:!RC4:!MD5:!DES:!aNULL:!eNULL ssl_dh_parameters_length = 4096
Kissing SSLv3 good bye did not cause harm to clients. Next to be phased out is 3DES which accounts for 0.25% o the connexions according to the logs. I suspect the offending clients could do better.
-- Emmanuel Dreyfus manu@netbsd.org
On 05/26/2015 10:37 AM, Ron Leach wrote:
https://weakdh.org/sysadmin.html
includes altering DH parameters length to 2048, and re-specifying the allowable cipher suites - they give their suggestion.
It looks like there is an error on this page regarding regeneration. In current dovecots ssl_parameters_regenerate defaults to zero, and this means regeneration is disabled. The old default was 168 hours (1 week). The language on http://wiki2.dovecot.org/SSL/DovecotConfiguration is confusing and could be understood to mean that the current default is one week. To enable regeneration you can manually set: ssl_parameters_regenerate = 60 days or: ssl_parameters_regenerate = 1 weeks
Quoting Gedalya gedalya@gedalya.net:
On 05/26/2015 10:37 AM, Ron Leach wrote:
https://weakdh.org/sysadmin.html
includes altering DH parameters length to 2048, and re-specifying the allowable cipher suites - they give their suggestion.
It looks like there is an error on this page regarding regeneration. In current dovecots ssl_parameters_regenerate defaults to zero, and this means regeneration is disabled. The old default was 168 hours (1 week). The language on http://wiki2.dovecot.org/SSL/DovecotConfiguration is confusing and could be understood to mean that the current default is one week. To enable regeneration you can manually set: ssl_parameters_regenerate = 60 days or:ssl_parameters_regenerate = 1 weeks
This is really cool and all, but for a low power proxy, it takes a good 5 minutes to regenerate the dh params, and Dovecot listens the entire time.
If the socket were closed during regeneration, then a (basic) front-end load balancer wouldn't still push connections to that proxy during regen.
Rick
On 05/27/2015 09:55 AM, Rick Romero wrote:
Quoting Gedalya gedalya@gedalya.net:
On 05/26/2015 10:37 AM, Ron Leach wrote:
https://weakdh.org/sysadmin.html
includes altering DH parameters length to 2048, and re-specifying the allowable cipher suites - they give their suggestion.
It looks like there is an error on this page regarding regeneration. In current dovecots ssl_parameters_regenerate defaults to zero, and this means regeneration is disabled. The old default was 168 hours (1 week). The language on http://wiki2.dovecot.org/SSL/DovecotConfiguration is confusing and could be understood to mean that the current default is one week. To enable regeneration you can manually set: ssl_parameters_regenerate = 60 days or:ssl_parameters_regenerate = 1 weeks
This is really cool and all, but for a low power proxy, it takes a good 5 minutes to regenerate the dh params, and Dovecot listens the entire time.
If the socket were closed during regeneration, then a (basic) front-end load balancer wouldn't still push connections to that proxy during regen.
Rick
I wonder if what is taking 5 minutes is CPU usage or entropy starvation. Might be worth looking into.
However the entire reason why I wrote this comment was to correct the mistaken line saying "#regenerates every week". It is not at this point emphasized anywhere, including on weakdh.org, that it is actually of high importance to regenerate your DH parameters frequently. This has been discussed extensively e.g. within the exim project and other places, and on dovecot too the default was changed to not regenerate. It seems that people are mostly just saying you should have locally generated parameters unique to your site.
But to address your point, if this feature is deemed worth maintaining, it seems it would be best to spawn a thread working on the new parameters in the background and replacing them when ready.
Otherwise dovecot can just implement a dh_parameters config option like all other daemons and you can maintain that externally as you please. But we're supposed to be focusing on EC anyway :-)
Quoting Gedalya gedalya@gedalya.net:
On 05/27/2015 09:55 AM, Rick Romero wrote:
Quoting Gedalya gedalya@gedalya.net:
On 05/26/2015 10:37 AM, Ron Leach wrote:
https://weakdh.org/sysadmin.html
includes altering DH parameters length to 2048, and re-specifying the allowable cipher suites - they give their suggestion.
It looks like there is an error on this page regarding regeneration. In current dovecots ssl_parameters_regenerate defaults to zero, and this means regeneration is disabled. The old default was 168 hours (1 week). The language on http://wiki2.dovecot.org/SSL/DovecotConfiguration is confusing and could be understood to mean that the current default is one week. To enable regeneration you can manually set: ssl_parameters_regenerate = 60 days or:ssl_parameters_regenerate = 1 weeks
This is really cool and all, but for a low power proxy, it takes a good 5 minutes to regenerate the dh params, and Dovecot listens the entire time.
If the socket were closed during regeneration, then a (basic) front-end load balancer wouldn't still push connections to that proxy during regen.
Rick
I wonder if what is taking 5 minutes is CPU usage or entropy starvation. Might be worth looking into.
I'd say CPU usage - I have two identical VMs for dovecot proxies, one is hosted on a dual Xeon 5450, the other a dual Opteron 2347HE. Both hosts are under similar load, but the Xeon host was done within 30 seconds. I assume the Xeon, besides having a faster base CPU frequency, is just better for that sort of workload.
I noticed a similar difference when generating params for the web servers, but I did that externally.
I assume it'd probably be easier to do the dh_parameters config than to fully disable the socket during regen..
Rick
On 05/27/2015 11:56 AM, Rick Romero wrote:
Quoting Gedalya gedalya@gedalya.net:
On 05/27/2015 09:55 AM, Rick Romero wrote:
Quoting Gedalya gedalya@gedalya.net:
On 05/26/2015 10:37 AM, Ron Leach wrote:
https://weakdh.org/sysadmin.html
includes altering DH parameters length to 2048, and re-specifying the allowable cipher suites - they give their suggestion.
It looks like there is an error on this page regarding regeneration. In current dovecots ssl_parameters_regenerate defaults to zero, and this means regeneration is disabled. The old default was 168 hours (1 week). The language on http://wiki2.dovecot.org/SSL/DovecotConfiguration is confusing and could be understood to mean that the current default is one week. To enable regeneration you can manually set: ssl_parameters_regenerate = 60 days or:ssl_parameters_regenerate = 1 weeks
This is really cool and all, but for a low power proxy, it takes a good 5 minutes to regenerate the dh params, and Dovecot listens the entire time.
If the socket were closed during regeneration, then a (basic) front-end load balancer wouldn't still push connections to that proxy during regen.
Rick
I wonder if what is taking 5 minutes is CPU usage or entropy starvation. Might be worth looking into.
I'd say CPU usage - I have two identical VMs for dovecot proxies, one is hosted on a dual Xeon 5450, the other a dual Opteron 2347HE. Both hosts are under similar load, but the Xeon host was done within 30 seconds. I assume the Xeon, besides having a faster base CPU frequency, is just better for that sort of workload.
I noticed a similar difference when generating params for the web servers, but I did that externally.
I assume it'd probably be easier to do the dh_parameters config than to fully disable the socket during regen..
Rick
Are the results repeatable? The time it takes openssl to generate new params is, well, literally random. I wish someone could tell me why, but 'certtool --generate-dh-params --bits 2048' (from gnutls) takes just a few seconds, and openssl can take several minutes. And BTW on second thought I think openssl doesn't actually read much from /dev/random but just uses its own PRNG so entropy starvation might not actually apply here. So yea it's just CPU and sheer luck in terms of how quickly it stumbles upon the right primes. As for gnutls - I have no idea how that works, but it's very fast.
Anyway I've certainly seen newer Xeons than 5450 take well over 30 seconds to generate 2048-bit dh params. If yours consistently does it in 30 seconds then I'd love to understand how come.
On 27/05/2015 05:22, Gedalya wrote:
It looks like there is an error on this page regarding regeneration. In current dovecots ssl_parameters_regenerate defaults to zero, and this means regeneration is disabled. The old default was 168 hours (1 week). The language on http://wiki2.dovecot.org/SSL/DovecotConfiguration is confusing and could be understood to mean that the current default is one week.
I'd read that dovecot wiki page, and the weakdh page, and - indeed - formed the impression that the defaults on our server were ok.
To enable regeneration you can manually set: ssl_parameters_regenerate = 60 days or: ssl_parameters_regenerate = 1 weeks
I couldn't find an entry in 10-ssl.config that covered regeneration (though our version is 2.2.15 and the current release, 2.2.18, may differ).
I created an entry from scratch, with the example you posted but set to 7 days, and placed that in 10-ssl.config .
Thank you very much for the advice.
regards, Ron
On 05/27/2015 12:15 PM, Ron Leach wrote:
I couldn't find an entry in 10-ssl.config that covered regeneration (though our version is 2.2.15 and the current release, 2.2.18, may differ).
Yea it's just not there. You can 'discover' these 'hidden' options using doveconf -a, scattered docs, and the source code ;-)
participants (5)
-
Emmanuel Dreyfus
-
Gedalya
-
Rick Romero
-
Robert Schetterer
-
Ron Leach