FREAK/Logjam, and SSL protocols to use

[Gedalya]

On 05/27/2015 11:56 AM, Rick Romero wrote:
>  Quoting Gedalya <gedalya at gedalya.net>:
>
>> On 05/27/2015 09:55 AM, Rick Romero wrote:
>>> Quoting Gedalya <gedalya at 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.