Hello Michael,

Michael Tremer:
> Hi,
> 
> On Wed, 2015-06-03 at 10:27 +0200, IT Superhack wrote:
>> Hello Michael,
>>
>> I tested a bit in the last hours. There were a few issues I discovered
>> and I had to change my patch.
>>
>> First, the prime number generation is much slower than I expected - it
>> took up to 20 minutes on my system. (I guess I had a lucky moment when I
>> wrote the last mail to you...)
> 
> That is a no-go then. The key will be generated when the system boots up
> for the first time. Nobody will wait half an hour until that has
> completed. We always prefer security over usability but it must still be
> possible to set up a fresh system within minutes.
I expected this answer and completly agree with you. If a user has to
wait 1-2 minutes, fine. But 20 minutes are way too much.
> 
> I am not opposed to the idea in general. In fact I would like to use an
> own DH key for each system as this patch suggests, but the solution must
> be less interruptive to the user.
Hm, I'm afraid the solution of this won't be very easy, but I'm going to
think about it.
> 
>> Second, Apache seems to ignore the DH prime numbers. On
>> https://weakdh.org/sysadmin.html it says that Apache 2.4.8 or newer is
>> required for the "SSLOpenSSLConfCmd" option.
>>
>> I have therefore decided to switch DH off, and use ECDHE only, which is
>> more safe and - by the way - faster than DH. This is not a problem,
>> because modern browsers support ECDHE, except for some exotic clients
>> such as Android 2.3.7 and Java Client 6u45.
> 
> We can definitely not use only ECDHE. Many OSes do not support elliptic
> curve cryptography not only because of their age but often because of
> patents.
Oh yes, I forgot.
> 
> RedHat still disables all ECC in openssl for all their distributions.
Could you update Apache to 2.4.8 or newer? Then the "SSLOpenSSLConfCmd"
would be supported and _this_ part of the problem would be solved.
> 
>> And yes, you were right: The DES-suites were ignored. Please see the new
>> cipher list in the patch below. In my opinion, the patch is now ready
>> for merging, unless you have someting against it.
>>
>> Signed-off-by: Timmothy Wilson <itsuperhack(a)web.de>
>> ---
>> diff --git a/config/httpd/vhosts.d/ipfire-interface-ssl.conf
>> b/config/httpd/vhosts.d/ipfire-interface-ssl.conf
>> index daac757..a8bbae7 100644
>> --- a/config/httpd/vhosts.d/ipfire-interface-ssl.conf
>> +++ b/config/httpd/vhosts.d/ipfire-interface-ssl.conf
>> @@ -9,7 +9,7 @@
>>      TransferLog /var/log/httpd/access_log
>>      SSLEngine on
>>      SSLProtocol all -SSLv2 -SSLv3
>> -    SSLCipherSuite
>> 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:AES256:HIGH:!RC4:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK
>> +    SSLCipherSuite
>> 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:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:CAMELLIA:HIGH:!DH:!LOW:!aNULL:!eNULL:!EXPORT:!3DES:!DES:!RC4:!MD5:!PSK:!aECDH
>>      SSLHonorCipherOrder on
>>      SSLCertificateFile /etc/httpd/server.crt
>>      SSLCertificateKeyFile /etc/httpd/server.key
> 
>> Sorry for my harsh words in my last mail about pseudonyms and this stuff.
> 
> No worries.
> 
>>
>> Best regards,
>> Timmothy Wilson
> 
> -Michael
> 
So, to sum it up, there are two things to do:
1: Find a way so generating DH group doesn't block the user for hours
2: Find a way to use DH "safe" for legacy clients (might be solved by
updating Apache)

Best regards,
Timmothy Wilson