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

  Hello Michael,

Michael Tremer:
> On Mon, 2015-06-01 at 09:13 +0200, IT Superhack wrote:
>> Hello Michael,
>>
>> Michael Tremer:
>>> On Sun, 2015-05-31 at 22:11 +0200, Stefan Schantl wrote:
>>>> Hello Timmothy,
>>>>
>>>> thanks for your hard work and sending us the patches. I've
>>>> noticed you already have read through the "Submiting Patches"
>>>> guide on the wiki (http://wiki.ipfire.org/devel/submit-patches).
>>>>
>>>> In order for an easy apply of your modifications please re-send
>>>> them to the list with the patchfile attached to the mail.
>>>
>>> No, no attachments.
>>>
>>> http://wiki.ipfire.org/devel/submit-patches#no_mime_no_links_no_compre
>> ssion_no_attachments_just_plain_text
>> As
>>>
>> Stefan already estimated, I've read those wiki pages.
>> But I've uploaded the patch to nopaste.ipfire.org due to cryappy line
>> breaks done by my mail program (I guess it has something to do with
>> PGP, but I don't know it for sure.).
> 
> Yes, most MUAs scramble the content of the emails quite a lot. If you
> set it to send a text email (which is a must on mailing lists any way)
> they do not tend to do that any more.
Indeed, they do. :-(
> 
> It is probably best to use git send-email because of these broken MUAs.
This does not work for me, but it seems to be an issue related to my
installation, i will check that later.
> 
>> So, if you like, I can attach the patch to an email, but I really
>> can't guarantee that it arrives correctly.
> 
> You can try sending emails to yourself to test your setup and look at
> the result.
I did several times, the solution was to set PGP to "PGP/MIME" instead
of signing inline.
> 
>>> Also no pseudonyms.
>> What is that supposed to mean?
> 
> We are legally required to have the real name of the author of a patch
> and a working email address.
> 
> The reasons behind that are quite a lot and have been discussed a couple
> of times on this list.
> 
> All the big Open Source projects I know require this, too.
Ah, I see.
> 
>>> I get that this entire process might be a bit difficult for a start
>>> but there has been put a lot of thought into it why we are doing it
>>> this way.
>> Both aspects are right: It is complicated to clone the git branch,
>> make patchfiles, working with git (first time!) and so on. But those
>> things seem to be useful for you developers.
> 
> Git is really complicated for beginners. Once you get used to it you
> will never want to use anything else. There are a lot of really nice
> howtos on the web and YouTube.
> 
> The patch format is so important because it saves a lot of work at the
> maintainers' part and you can probably describe best what your patch is
> supposed to fix and so on.
So, here finally is my patch:
Signed-off-by: Timmothy Wilson <itsuperhack@web.de>
---

/etc/httpd/server.csr ]; then

Please let me know if there are any issues or the patch didn't arrived
correctly. Please also note my comments below about how to distribute
and apply the patch.

> 
> -Michael
> 
>>
>> Best regards,
>> Timmothy Wilson
>>>
>>> Best, -Michael
>>>
>>>> Thanks in advance,
>>>>
>>>> -Stefan
>>>>
>>>>
>>>>> Changes: [1] Forbid the use of weak DH cipher suites in
>>>>> Apache. [2] Tell Apache to use a custom bunch of prime
>>>>> numbers. [3] Updated "httpscert" in order to generate those
>>>>> prime numbers.
>>>>>
>>>>> Those changes are supposed to fix a vulnerability called
>>>>> "logjam" in Apache. "Logjam" is a recently discovered
>>>>> vulnerability in the Diffie-Hellman-Key-Exchange. Affected are
>>>>> TLS/SSL connectiones, VPNs and other services which are relying
>>>>> on DH as well.
>>>>>
>>>>> References: [Bug #10856]:
>>>>> https://bugzilla.ipfire.org/show_bug.cgi?id=10856 [Further
>>>>> Information]: https://weakdh.org/ [Further Information
>>>>> (german)]: 
>>>>> http://www.heise.de/security/meldung/Logjam-Attacke-Verschluesselung
>> -von
>>>>>
>>>>>
>> -zehntausenden-Servern-gefaehrdet-2657502.html
>>>>>
>>>>> Please find the patch here:
>>>>> http://nopaste.ipfire.org/view/r8QWUyQF
>>>>>
>>>>> However, the patch can't applied to IPFire systems without
>>>>> creating unique prime numbers, since the configuration file of
>>>>> Apache expects the presence of a file called
>>>>> "/etc/httpd/dhparams.pem", if this one does not exist, Apache
>>>>> will likely crash. Please make sure to generate prime numbers
>>>>> by Pakfire during a upgrade:
>>>>>
>>>>> /usr/bin/openssl dhparam -out /etc/httpd/dhparams.pem 2048;
This is still the case, please make sure to run this command after an
upgrade.
>>>>>
>>>>> I'm estimating that other software components of IPFire are
>>>>> still vulnerable to Lojgam (IPSec?). As soon as I have more
>>>>> information about this, I will roll out new patches.
>>>>>
>>>>> Best regards, Timmothy Wilson 
>>>>> _______________________________________________ Development
>>>>> mailing list Development@lists.ipfire.org 
>>>>> http://lists.ipfire.org/mailman/listinfo/development
>>>>
>>>> _______________________________________________ Development
>>>> mailing list Development@lists.ipfire.org 
>>>> http://lists.ipfire.org/mailman/listinfo/development
>>>>
>>>>
>>>> _______________________________________________ Development
>>>> mailing list Development@lists.ipfire.org 
>>>> http://lists.ipfire.org/mailman/listinfo/development
>>
Best regards,
Timmothy Wilson
  

On Tue, 2015-06-02 at 18:32 +0200, IT Superhack wrote:
> Hello Michael,
> 
> Michael Tremer:
> > On Mon, 2015-06-01 at 09:13 +0200, IT Superhack wrote:
> >> Hello Michael,
> >>
> >> Michael Tremer:
> >>> On Sun, 2015-05-31 at 22:11 +0200, Stefan Schantl wrote:
> >>>> Hello Timmothy,
> >>>>
> >>>> thanks for your hard work and sending us the patches. I've
> >>>> noticed you already have read through the "Submiting Patches"
> >>>> guide on the wiki (http://wiki.ipfire.org/devel/submit-patches).
> >>>>
> >>>> In order for an easy apply of your modifications please re-send
> >>>> them to the list with the patchfile attached to the mail.
> >>>
> >>> No, no attachments.
> >>>
> >>> http://wiki.ipfire.org/devel/submit-patches#no_mime_no_links_no_compre
> >> ssion_no_attachments_just_plain_text
> >> As
> >>>
> >> Stefan already estimated, I've read those wiki pages.
> >> But I've uploaded the patch to nopaste.ipfire.org due to cryappy line
> >> breaks done by my mail program (I guess it has something to do with
> >> PGP, but I don't know it for sure.).
> > 
> > Yes, most MUAs scramble the content of the emails quite a lot. If you
> > set it to send a text email (which is a must on mailing lists any way)
> > they do not tend to do that any more.
> Indeed, they do. :-(
> > 
> > It is probably best to use git send-email because of these broken MUAs.
> This does not work for me, but it seems to be an issue related to my
> installation, i will check that later.
> > 
> >> So, if you like, I can attach the patch to an email, but I really
> >> can't guarantee that it arrives correctly.
> > 
> > You can try sending emails to yourself to test your setup and look at
> > the result.
> I did several times, the solution was to set PGP to "PGP/MIME" instead
> of signing inline.
> > 
> >>> Also no pseudonyms.
> >> What is that supposed to mean?
> > 
> > We are legally required to have the real name of the author of a patch
> > and a working email address.
> > 
> > The reasons behind that are quite a lot and have been discussed a couple
> > of times on this list.
> > 
> > All the big Open Source projects I know require this, too.
> Ah, I see.
> > 
> >>> I get that this entire process might be a bit difficult for a start
> >>> but there has been put a lot of thought into it why we are doing it
> >>> this way.
> >> Both aspects are right: It is complicated to clone the git branch,
> >> make patchfiles, working with git (first time!) and so on. But those
> >> things seem to be useful for you developers.
> > 
> > Git is really complicated for beginners. Once you get used to it you
> > will never want to use anything else. There are a lot of really nice
> > howtos on the web and YouTube.
> > 
> > The patch format is so important because it saves a lot of work at the
> > maintainers' part and you can probably describe best what your patch is
> > supposed to fix and so on.
> So, here finally is my patch:
> Signed-off-by: Timmothy Wilson <itsuperhack@web.de>

Could you please provide any sort of proof that this is not a pseudonym?

> ---
> 
> diff --git a/config/httpd/vhosts.d/ipfire-interface-ssl.conf
> b/config/httpd/vhosts.d/ipfire-interface-ssl.conf
> index daac757..b4ad035 100644
> --- a/config/httpd/vhosts.d/ipfire-interface-ssl.conf
> +++ b/config/httpd/vhosts.d/ipfire-interface-ssl.conf
> @@ -9,10 +9,11 @@
>      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: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:AES256-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

I did not get from the description of the patch why these cipher suites
are added at the end. They should not be allowed any way as they contain
DES and some other ciphers that have been forbidden before.

>      SSLHonorCipherOrder on
>      SSLCertificateFile /etc/httpd/server.crt
>      SSLCertificateKeyFile /etc/httpd/server.key
> +    SSLOpenSSLConfCmd DHParameters "/etc/httpd/dhparams.pem"
> 
>      <Directory /srv/web/ipfire/html>
>          Options ExecCGI
> @@ -59,33 +60,33 @@
>          Require user dial admin
>      </Directory>
>      <Files ~ "\.(cgi|shtml?)$">
> -	SSLOptions +StdEnvVars
> +        SSLOptions +StdEnvVars
>      </Files>
>      <Directory /srv/web/ipfire/cgi-bin>
> -	SSLOptions +StdEnvVars
> +        SSLOptions +StdEnvVars
>      </Directory>
>      SetEnv HOME /home/nobody
>      SetEnvIf User-Agent ".*MSIE.*" \
> -	nokeepalive ssl-unclean-shutdown \
> -	downgrade-1.0 force-response-1.0
> +        nokeepalive ssl-unclean-shutdown \
> +        downgrade-1.0 force-response-1.0
>      CustomLog /var/log/httpd/ssl_request_log \
> -	"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
> +        "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
> 
>      Alias /updatecache/ /var/updatecache/
> -	<Directory /var/updatecache>
> -		 Options ExecCGI
> -		 AllowOverride None
> -		 Order deny,allow
> -		 Allow from all
> -	</Directory>
> +        <Directory /var/updatecache>
> +                 Options ExecCGI
> +                 AllowOverride None
> +                 Order deny,allow
> +                 Allow from all
> +        </Directory>
> 
>      Alias /repository/ /var/urlrepo/
> -	<Directory /var/urlrepo>
> -		 Options ExecCGI
> -		 AllowOverride None
> -		 Order deny,allow
> -		 Allow from all
> -	</Directory>
> +        <Directory /var/urlrepo>
> +                 Options ExecCGI
> +                 AllowOverride None
> +                 Order deny,allow
> +                 Allow from all
> +        </Directory>

It would also have been nice to have an extra patch just for
re-indentation.

> 
>      Alias /proxy-reports/ /var/log/sarg/
>      <Directory /var/log/sarg>
> @@ -96,4 +97,4 @@
>          AuthUserFile /var/ipfire/auth/users
>          Require user admin
>      </Directory>
> -</VirtualHost>
> +</VirtualHost>
> \ No newline at end of file

Please do not remove the newline at the end of files.

> diff --git a/src/scripts/httpscert b/src/scripts/httpscert
> index e20f789..61abcda 100644
> --- a/src/scripts/httpscert
> +++ b/src/scripts/httpscert
> @@ -17,6 +17,8 @@ case "$1" in
>  	/usr/bin/openssl x509 -req -days 999999 -sha256 -in \
>  		/etc/httpd/server.csr -signkey /etc/httpd/server.key -out \
>  		/etc/httpd/server.crt
> +	echo "Generating prime numbers...";
> +	/usr/bin/openssl dhparam -out /etc/httpd/dhparams.pem 2048;
>   	;;
>    read)
>  	if [ -f /etc/httpd/server.key -a -f /etc/httpd/server.crt -a -f
> /etc/httpd/server.csr ]; then

Do you have any benchmarks about how long this approximately takes to
generate? I estimate this taking hours on some hardware.

> Please let me know if there are any issues or the patch didn't arrived
> correctly. Please also note my comments below about how to distribute
> and apply the patch.

You can check if the patch made its way through here:

  http://patchwork.ipfire.org/project/ipfire/list/

What comments below? I could not find any.

Best,
-Michael

> 
> > 
> > -Michael
> > 
> >>
> >> Best regards,
> >> Timmothy Wilson
> >>>
> >>> Best, -Michael
> >>>
> >>>> Thanks in advance,
> >>>>
> >>>> -Stefan
> >>>>
> >>>>
> >>>>> Changes: [1] Forbid the use of weak DH cipher suites in
> >>>>> Apache. [2] Tell Apache to use a custom bunch of prime
> >>>>> numbers. [3] Updated "httpscert" in order to generate those
> >>>>> prime numbers.
> >>>>>
> >>>>> Those changes are supposed to fix a vulnerability called
> >>>>> "logjam" in Apache. "Logjam" is a recently discovered
> >>>>> vulnerability in the Diffie-Hellman-Key-Exchange. Affected are
> >>>>> TLS/SSL connectiones, VPNs and other services which are relying
> >>>>> on DH as well.
> >>>>>
> >>>>> References: [Bug #10856]:
> >>>>> https://bugzilla.ipfire.org/show_bug.cgi?id=10856 [Further
> >>>>> Information]: https://weakdh.org/ [Further Information
> >>>>> (german)]: 
> >>>>> http://www.heise.de/security/meldung/Logjam-Attacke-Verschluesselung
> >> -von
> >>>>>
> >>>>>
> >> -zehntausenden-Servern-gefaehrdet-2657502.html
> >>>>>
> >>>>> Please find the patch here:
> >>>>> http://nopaste.ipfire.org/view/r8QWUyQF
> >>>>>
> >>>>> However, the patch can't applied to IPFire systems without
> >>>>> creating unique prime numbers, since the configuration file of
> >>>>> Apache expects the presence of a file called
> >>>>> "/etc/httpd/dhparams.pem", if this one does not exist, Apache
> >>>>> will likely crash. Please make sure to generate prime numbers
> >>>>> by Pakfire during a upgrade:
> >>>>>
> >>>>> /usr/bin/openssl dhparam -out /etc/httpd/dhparams.pem 2048;
> This is still the case, please make sure to run this command after an
> upgrade.
> >>>>>
> >>>>> I'm estimating that other software components of IPFire are
> >>>>> still vulnerable to Lojgam (IPSec?). As soon as I have more
> >>>>> information about this, I will roll out new patches.
> >>>>>
> >>>>> Best regards, Timmothy Wilson 
> >>>>> _______________________________________________ Development
> >>>>> mailing list Development@lists.ipfire.org 
> >>>>> http://lists.ipfire.org/mailman/listinfo/development
> >>>>
> >>>> _______________________________________________ Development
> >>>> mailing list Development@lists.ipfire.org 
> >>>> http://lists.ipfire.org/mailman/listinfo/development
> >>>>
> >>>>
> >>>> _______________________________________________ Development
> >>>> mailing list Development@lists.ipfire.org 
> >>>> http://lists.ipfire.org/mailman/listinfo/development
> >>
> Best regards,
> Timmothy Wilson
> 
>
  

Hello Michael,
Michael Tremer:> On Tue, 2015-06-02 at 18:32 +0200, IT Superhack wrote:
>> Hello Michael,
>>
>> Michael Tremer:
>>> On Mon, 2015-06-01 at 09:13 +0200, IT Superhack wrote:
>>>> Hello Michael,
>>>>
>>>> Michael Tremer:
>>>>> On Sun, 2015-05-31 at 22:11 +0200, Stefan Schantl wrote:
>>>>>> Hello Timmothy,
>>>>>>
>>>>>> thanks for your hard work and sending us the patches. I've
>>>>>> noticed you already have read through the "Submiting Patches"
>>>>>> guide on the wiki (http://wiki.ipfire.org/devel/submit-patches).
>>>>>>
>>>>>> In order for an easy apply of your modifications please re-send
>>>>>> them to the list with the patchfile attached to the mail.
>>>>>
>>>>> No, no attachments.
>>>>>
>>>>> http://wiki.ipfire.org/devel/submit-patches#no_mime_no_links_no_compre
>>>> ssion_no_attachments_just_plain_text
>>>> As
>>>>>
>>>> Stefan already estimated, I've read those wiki pages.
>>>> But I've uploaded the patch to nopaste.ipfire.org due to cryappy line
>>>> breaks done by my mail program (I guess it has something to do with
>>>> PGP, but I don't know it for sure.).
>>>
>>> Yes, most MUAs scramble the content of the emails quite a lot. If you
>>> set it to send a text email (which is a must on mailing lists any way)
>>> they do not tend to do that any more.
>> Indeed, they do. :-(
>>>
>>> It is probably best to use git send-email because of these broken MUAs.
>> This does not work for me, but it seems to be an issue related to my
>> installation, i will check that later.
>>>
>>>> So, if you like, I can attach the patch to an email, but I really
>>>> can't guarantee that it arrives correctly.
>>>
>>> You can try sending emails to yourself to test your setup and look at
>>> the result.
>> I did several times, the solution was to set PGP to "PGP/MIME" instead
>> of signing inline.
>>>
>>>>> Also no pseudonyms.
>>>> What is that supposed to mean?
>>>
>>> We are legally required to have the real name of the author of a patch
>>> and a working email address.
>>>
>>> The reasons behind that are quite a lot and have been discussed a couple
>>> of times on this list.
>>>
>>> All the big Open Source projects I know require this, too.
>> Ah, I see.
>>>
>>>>> I get that this entire process might be a bit difficult for a start
>>>>> but there has been put a lot of thought into it why we are doing it
>>>>> this way.
>>>> Both aspects are right: It is complicated to clone the git branch,
>>>> make patchfiles, working with git (first time!) and so on. But those
>>>> things seem to be useful for you developers.
>>>
>>> Git is really complicated for beginners. Once you get used to it you
>>> will never want to use anything else. There are a lot of really nice
>>> howtos on the web and YouTube.
>>>
>>> The patch format is so important because it saves a lot of work at the
>>> maintainers' part and you can probably describe best what your patch is
>>> supposed to fix and so on.
>> So, here finally is my patch:
>> Signed-off-by: Timmothy Wilson <itsuperhack@web.de>
>
> Could you please provide any sort of proof that this is not a pseudonym?
How should I do that? I will certainly not send you a copy of my
identity card, if you're meaning that. By the way, there is no (useful)
possibility to make sure that an email address or a chat account belongs
to a real person.

I'm sending in patches to help the developers and to provide fixes for
bugs, security issues etc. to other users. The systems I own are already
patched, this is not why I'm doing this here.
However, if you don't like my patches (for whatever reason), please just
tell me so. It would save time for both of us.
>
>> ---
>>
>> diff --git a/config/httpd/vhosts.d/ipfire-interface-ssl.conf
>> b/config/httpd/vhosts.d/ipfire-interface-ssl.conf
>> index daac757..b4ad035 100644
>> --- a/config/httpd/vhosts.d/ipfire-interface-ssl.conf
>> +++ b/config/httpd/vhosts.d/ipfire-interface-ssl.conf
>> @@ -9,10 +9,11 @@
>>      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: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:AES256-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
>
> I did not get from the description of the patch why these cipher suites
> are added at the end. They should not be allowed any way as they contain
> DES and some other ciphers that have been forbidden before.
Sorry, I don't know what you mean. The list of cipher suites is
basically the same as before. The only thing which has changed are the
"AES" cipher suites at the end and that some combination of cipher list
are forbidden by a separate definition.

I suppose it might be okay to leave those cipher suites out, but I'm not
really sure - in some cases, I've already noticed that the "forbidden"
list (!RC4, ...) was not handled correctly. So I guess it's more safe to
leave these suites where they are.
>
>>      SSLHonorCipherOrder on
>>      SSLCertificateFile /etc/httpd/server.crt
>>      SSLCertificateKeyFile /etc/httpd/server.key
>> +    SSLOpenSSLConfCmd DHParameters "/etc/httpd/dhparams.pem"
>>
>>      <Directory /srv/web/ipfire/html>
>>          Options ExecCGI
>> @@ -59,33 +60,33 @@
>>          Require user dial admin
>>      </Directory>
>>      <Files ~ "\.(cgi|shtml?)$">
>> -	SSLOptions +StdEnvVars
>> +        SSLOptions +StdEnvVars
>>      </Files>
>>      <Directory /srv/web/ipfire/cgi-bin>
>> -	SSLOptions +StdEnvVars
>> +        SSLOptions +StdEnvVars
>>      </Directory>
>>      SetEnv HOME /home/nobody
>>      SetEnvIf User-Agent ".*MSIE.*" \
>> -	nokeepalive ssl-unclean-shutdown \
>> -	downgrade-1.0 force-response-1.0
>> +        nokeepalive ssl-unclean-shutdown \
>> +        downgrade-1.0 force-response-1.0
>>      CustomLog /var/log/httpd/ssl_request_log \
>> -	"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
>> +        "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
>>
>>      Alias /updatecache/ /var/updatecache/
>> -	<Directory /var/updatecache>
>> -		 Options ExecCGI
>> -		 AllowOverride None
>> -		 Order deny,allow
>> -		 Allow from all
>> -	</Directory>
>> +        <Directory /var/updatecache>
>> +                 Options ExecCGI
>> +                 AllowOverride None
>> +                 Order deny,allow
>> +                 Allow from all
>> +        </Directory>
>>
>>      Alias /repository/ /var/urlrepo/
>> -	<Directory /var/urlrepo>
>> -		 Options ExecCGI
>> -		 AllowOverride None
>> -		 Order deny,allow
>> -		 Allow from all
>> -	</Directory>
>> +        <Directory /var/urlrepo>
>> +                 Options ExecCGI
>> +                 AllowOverride None
>> +                 Order deny,allow
>> +                 Allow from all
>> +        </Directory>
>
> It would also have been nice to have an extra patch just for
> re-indentation.
Those were not done my be. I will rework the patch so that it just
contains the changes which are necessary for fixing logjam.
>
>>
>>      Alias /proxy-reports/ /var/log/sarg/
>>      <Directory /var/log/sarg>
>> @@ -96,4 +97,4 @@
>>          AuthUserFile /var/ipfire/auth/users
>>          Require user admin
>>      </Directory>
>> -</VirtualHost>
>> +</VirtualHost>
>> \ No newline at end of file
>
> Please do not remove the newline at the end of files.
Okay.
>
>> diff --git a/src/scripts/httpscert b/src/scripts/httpscert
>> index e20f789..61abcda 100644
>> --- a/src/scripts/httpscert
>> +++ b/src/scripts/httpscert
>> @@ -17,6 +17,8 @@ case "$1" in
>>  	/usr/bin/openssl x509 -req -days 999999 -sha256 -in \
>>  		/etc/httpd/server.csr -signkey /etc/httpd/server.key -out \
>>  		/etc/httpd/server.crt
>> +	echo "Generating prime numbers...";
>> +	/usr/bin/openssl dhparam -out /etc/httpd/dhparams.pem 2048;
>>   	;;
>>    read)
>>  	if [ -f /etc/httpd/server.key -a -f /etc/httpd/server.crt -a -f
>> /etc/httpd/server.csr ]; then
>
> Do you have any benchmarks about how long this approximately takes to
> generate? I estimate this taking hours on some hardware.
I run the command:
/usr/bin/openssl dhparam -out benchmark.pem 2048
It took ~ 2.5 minutes on my Wandboard (without AES-NI/HWRNG).
Started 08:29:31
Finished 08:31:47
>
>> Please let me know if there are any issues or the patch didn't arrived
>> correctly. Please also note my comments below about how to distribute
>> and apply the patch.
>
> You can check if the patch made its way through here:
>
>   http://patchwork.ipfire.org/project/ipfire/list/
>
> What comments below? I could not find any.
I meant that you need to generate prime numbers by pakfire in case of an
update and that other software might still be vulnerable to logjam.

Best regards,
Timmothy Wilson
>
> Best,
> -Michael
>
>>
>>>
>>> -Michael
>>>
>>>>
>>>> Best regards,
>>>> Timmothy Wilson
>>>>>
>>>>> Best, -Michael
>>>>>
>>>>>> Thanks in advance,
>>>>>>
>>>>>> -Stefan
>>>>>>
>>>>>>
>>>>>>> Changes: [1] Forbid the use of weak DH cipher suites in
>>>>>>> Apache. [2] Tell Apache to use a custom bunch of prime
>>>>>>> numbers. [3] Updated "httpscert" in order to generate those
>>>>>>> prime numbers.
>>>>>>>
>>>>>>> Those changes are supposed to fix a vulnerability called
>>>>>>> "logjam" in Apache. "Logjam" is a recently discovered
>>>>>>> vulnerability in the Diffie-Hellman-Key-Exchange. Affected are
>>>>>>> TLS/SSL connectiones, VPNs and other services which are relying
>>>>>>> on DH as well.
>>>>>>>
>>>>>>> References: [Bug #10856]:
>>>>>>> https://bugzilla.ipfire.org/show_bug.cgi?id=10856 [Further
>>>>>>> Information]: https://weakdh.org/ [Further Information
>>>>>>> (german)]:
>>>>>>> http://www.heise.de/security/meldung/Logjam-Attacke-Verschluesselung
>>>> -von
>>>>>>>
>>>>>>>
>>>> -zehntausenden-Servern-gefaehrdet-2657502.html
>>>>>>>
>>>>>>> Please find the patch here:
>>>>>>> http://nopaste.ipfire.org/view/r8QWUyQF
>>>>>>>
>>>>>>> However, the patch can't applied to IPFire systems without
>>>>>>> creating unique prime numbers, since the configuration file of
>>>>>>> Apache expects the presence of a file called
>>>>>>> "/etc/httpd/dhparams.pem", if this one does not exist, Apache
>>>>>>> will likely crash. Please make sure to generate prime numbers
>>>>>>> by Pakfire during a upgrade:
>>>>>>>
>>>>>>> /usr/bin/openssl dhparam -out /etc/httpd/dhparams.pem 2048;
>> This is still the case, please make sure to run this command after an
>> upgrade.
>>>>>>>
>>>>>>> I'm estimating that other software components of IPFire are
>>>>>>> still vulnerable to Lojgam (IPSec?). As soon as I have more
>>>>>>> information about this, I will roll out new patches.
>>>>>>>
>>>>>>> Best regards, Timmothy Wilson
>>>>>>> _______________________________________________ Development
>>>>>>> mailing list Development@lists.ipfire.org
>>>>>>> http://lists.ipfire.org/mailman/listinfo/development
>>>>>>
>>>>>> _______________________________________________ Development
>>>>>> mailing list Development@lists.ipfire.org
>>>>>> http://lists.ipfire.org/mailman/listinfo/development
>>>>>>
>>>>>>
>>>>>> _______________________________________________ Development
>>>>>> mailing list Development@lists.ipfire.org
>>>>>> http://lists.ipfire.org/mailman/listinfo/development
>>>>
>> Best regards,
>> Timmothy Wilson
>>
>>