apache: generating unique prime numbers and forbit use of weak DH cipher suites

  Hello Michael,
Michael Tremer:
> Hi,
> 
> On Fri, 2015-06-05 at 20:25 +0200, IT Superhack wrote:
>> Michael Tremer:
>>> On Thu, 2015-06-04 at 21:48 +0200, IT Superhack wrote:
>>>> 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.
>>>
>>> For a start we could update apache and add a script that adds the DH
>>> params. In that way the security-aware users can execute the script,
>>> wait for an hour or so and then can use their own key.
>> That is a good idea. We can just use a version of "httpscert", which
>> would have an extra option, maybe "gendhparams" or something similar for
>> generating DH prime numbers.
> 
> Indeed it is a good idea to just extend that script.
Well, here you go:
Signed-off-by: Timmothy Wilson <itsuperhack@web.de>
---

> 
>> However, as you already said, this is not a permanent solution. Many
>> systems will be unprotected since their owners don't have the time to
>> run the script. We need something fast and maybe automated here, without
>> annoying the user.
>>
>> How about this scenario:
>> You (= the developers) ship a script with the next update. This script
>> generates DH primes in background and then modifies the apache config
>> file so it uses the DH primes after they have been successfully created.
>> This way, the user would not be blocked; the generation could also take
>> place at night, when usually nothing important else happens.
> 
> There are two things I am not entirely comfortable with:
> 
> a) Having a script changing a config file is not a good idea. We will
> need to put that one into the backup and that makes things a bit
> complicated. It would be better to have an extra file in the conf.d
> directory that is automatically included.
Hm, I'm not sure if this is possible, since you need to add the DH
params stuff into the configuration file of the virtual host listening
on port 444.
> 
> b) That the script is running in background is basically a good idea,
> but I am not sure if that should be triggered automatically. Some
> systems don't run at night. When we do that right after the first boot,
> people might need to reboot the system while they are still configuring
> things. Also if there is a time span of half an hour or an hour where
> the system unexpectedly for the user has 100% CPU usage, that will cause
> a lot of questions.
> 
> So I was thinking that we might have a button on the web user interface
> that reminds the user to perform that task. So he or she can decide when
> ever they want to generate the key. The web user interface could show
> some note at the bottom as long this process in running.
Great idea.
> 
> If the system is rebooted while the key generation is still in progress
> the user will have to click the button again. I think we should not
> block the reboot for that.
Yes, rebooting should be prohibited for this time.
> 
> The downside of this approach is that installing IPFire is becoming more
> complicated. I am not happy with that at all.
Setting up a firewall is never easy (and will never be). If somebody
really takes care about IT security in general, it will always take time
and work.
So, I think this would be acceptable since it is only a one-time
procedure you start when you set up IPFire.
> 
>> This would be also an idea for the installation. Only the HTTPS certs
>> are generated on the first boot, the DH prime can be created later or at
>> the users request. If some DH prime is present, a script updates the
>> apache config file.
>>>
>>> That way we can also get some more experience about how long the whole
>>> process takes and where potential problems are.
>> Provided that some people would like to share their results with us,
>> this would be nice.
>>>
>>> Apache has not been updated in recent time because the release we are
>>> currently using is still supported. But there is no reason why we should
>>> not try an update, either. Will you have a go at that?
>> I'm not sure what you're meaning with your last sentence (bad english,
>> sorry :-) ), but i can take care about this issue.
> 
> I was just asking if you want to try updating the apache package? The
> configuration files will have to be converted to the 2.4 format and
> there might be some other easter eggs to find.
I could try, but I'm afraid I'll need help here. Would it be possible
that you provide me an updated apache package? I could then take care
about the configuration stuff, but this might take a while.
> 
>>>
>>>>>> 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@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
>>>>
>>>>
>>>
>>> -Michael
>>>
>> Best regards,
>> Timmothy Wilson
> 
> -Michael
> 
Best regards,
Timmothy Wilson