Re: [PATCH] apache: generating unique prime numbers and forbit use of weak DH cipher suites

Re: [PATCH] apache: generating unique prime numbers and forbit use of weak DH cipher suites

[IT Superhack]

[-- Attachment #1: Type: text/plain, Size: 3956 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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.).

So, if you like, I can attach the patch to an email, but I really
can't guarantee that it arrives correctly.
> 
> Also no pseudonyms.
What is that supposed to mean?
> 
> 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.

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;
>>> 
>>> 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(a)lists.ipfire.org 
>>> http://lists.ipfire.org/mailman/listinfo/development
>> 
>> _______________________________________________ Development
>> mailing list Development(a)lists.ipfire.org 
>> http://lists.ipfire.org/mailman/listinfo/development
>> 
>> 
>> _______________________________________________ Development
>> mailing list Development(a)lists.ipfire.org 
>> http://lists.ipfire.org/mailman/listinfo/development

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJVbAY0AAoJEOyLa1C5Eazrg0QH/i9h/jLd8/9V5NBk0penKtsL
UEWEZFvho0LhmIzIEG2PeF7BvNxQt9XWwqJK9Te0NZ2WFD1rYNMyeWXJy1/oAsej
2WG6xIFEfXMXoxiuNVrHwQMSd2qVOcA+2b5VsayuseMP9h197cWyZqTyQtQFWWFE
B8ztprafNIxkmk0bGlaOzTgi5LATpkLwoBTlHNpTOSrsz/vghv6OMPIwdh3YN0rN
lFv089UqsQBMOXLFfPVvGEIdMiL7bUJHDd0CvkxfulzCJwp43DwpBtnY226ZmJYP
aMkmDoHQL9zLwNAuvCIx8zthsz4bubdloJBU8feM6aR430dRHsFkKlYf5z1JgVA=
=tuA9
-----END PGP SIGNATURE-----

Re: [PATCH] apache: generating unique prime numbers and forbit use of weak DH cipher suites

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 4635 bytes --]

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.

It is probably best to use git send-email because of these broken MUAs.

> 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.

> > 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.

> > 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.

-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;
> >>> 
> >>> 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(a)lists.ipfire.org 
> >>> http://lists.ipfire.org/mailman/listinfo/development
> >> 
> >> _______________________________________________ Development
> >> mailing list Development(a)lists.ipfire.org 
> >> http://lists.ipfire.org/mailman/listinfo/development
> >> 
> >> 
> >> _______________________________________________ Development
> >> mailing list Development(a)lists.ipfire.org 
> >> http://lists.ipfire.org/mailman/listinfo/development
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] apache: generating unique prime numbers and forbit use of weak DH cipher suites

[IT Superhack]

[-- Attachment #1: Type: text/plain, Size: 9681 bytes --]

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(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..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
     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>

     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
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

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(a)lists.ipfire.org 
>>>>> http://lists.ipfire.org/mailman/listinfo/development
>>>>
>>>> _______________________________________________ Development
>>>> mailing list Development(a)lists.ipfire.org 
>>>> http://lists.ipfire.org/mailman/listinfo/development
>>>>
>>>>
>>>> _______________________________________________ Development
>>>> mailing list Development(a)lists.ipfire.org 
>>>> http://lists.ipfire.org/mailman/listinfo/development
>>
Best regards,
Timmothy Wilson



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [PATCH] apache: generating unique prime numbers and forbit use of weak DH cipher suites

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 10962 bytes --]

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(a)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(a)lists.ipfire.org 
> >>>>> http://lists.ipfire.org/mailman/listinfo/development
> >>>>
> >>>> _______________________________________________ Development
> >>>> mailing list Development(a)lists.ipfire.org 
> >>>> http://lists.ipfire.org/mailman/listinfo/development
> >>>>
> >>>>
> >>>> _______________________________________________ Development
> >>>> mailing list Development(a)lists.ipfire.org 
> >>>> http://lists.ipfire.org/mailman/listinfo/development
> >>
> Best regards,
> Timmothy Wilson
> 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] apache: generating unique prime numbers and forbit use of weak DH cipher suites

[IT Superhack]

[-- Attachment #1: Type: text/plain, Size: 12673 bytes --]

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(a)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(a)lists.ipfire.org
>>>>>>> http://lists.ipfire.org/mailman/listinfo/development
>>>>>>
>>>>>> _______________________________________________ Development
>>>>>> mailing list Development(a)lists.ipfire.org
>>>>>> http://lists.ipfire.org/mailman/listinfo/development
>>>>>>
>>>>>>
>>>>>> _______________________________________________ Development
>>>>>> mailing list Development(a)lists.ipfire.org
>>>>>> http://lists.ipfire.org/mailman/listinfo/development
>>>>
>> Best regards,
>> Timmothy Wilson
>>
>>



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [PATCH] apache: generating unique prime numbers and forbit use of weak DH cipher suites

[IT Superhack]

[-- Attachment #1: Type: text/plain, Size: 2755 bytes --]

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...)
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.

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.

Best regards,
Timmothy Wilson



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [PATCH] apache: generating unique prime numbers and forbit use of weak DH cipher suites

[Larsen]

[-- Attachment #1: Type: text/plain, Size: 248 bytes --]

FWIMC:
The last two lines of the patch are missing in  
http://patchwork.ipfire.org/patch/12/

>      SSLCertificateFile /etc/httpd/server.crt
>      SSLCertificateKeyFile /etc/httpd/server.key

Instead, they show up as part of the comment.


Lars

Re: [PATCH] apache: generating unique prime numbers and forbit use of weak DH cipher suites

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 3609 bytes --]

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 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.

> 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.

RedHat still disables all ECC in openssl for all their distributions.

> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] apache: generating unique prime numbers and forbit use of weak DH cipher suites

[IT Superhack]

[-- Attachment #1: Type: text/plain, Size: 4362 bytes --]

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



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [PATCH] apache: generating unique prime numbers and forbit use of weak DH cipher suites

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 5126 bytes --]

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 way we can also get some more experience about how long the whole
process takes and where potential problems are.

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?

> >> 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
> 
> 

-Michael

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] apache: generating unique prime numbers and forbit use of weak DH cipher suites

[IT Superhack]

[-- Attachment #1: Type: text/plain, Size: 6461 bytes --]

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.

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.

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.
> 
>>>> 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
>>
>>
> 
> -Michael
> 
Best regards,
Timmothy Wilson



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [PATCH] apache: generating unique prime numbers and forbit use of weak DH cipher suites

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 8372 bytes --]

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.

> 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.

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.

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.

The downside of this approach is that installing IPFire is becoming more
complicated. I am not happy with that at all.

> 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.

> > 
> >>>> 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
> >>
> >>
> > 
> > -Michael
> > 
> Best regards,
> Timmothy Wilson

-Michael

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] apache: generating unique prime numbers and forbit use of weak DH cipher suites

[IT Superhack]

[-- Attachment #1: Type: text/plain, Size: 9717 bytes --]

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(a)web.de>
---
diff --git a/src/scripts/httpscert b/src/scripts/httpscert
index e20f789..50f96be 100644
--- a/src/scripts/httpscert
+++ b/src/scripts/httpscert
@@ -35,6 +35,10 @@ case "$1" in
 		exit 1
 	fi
 	;;
+  gendhparams)
+	echo "Generating prime numbers (may take a while)...";
+	/usr/bin/openssl dhparam -out /etc/httpd/dhparams.pem 2048;
+	;;
   *)
 	/bin/echo "Usage: $0 {read|new}"
 	exit 1

> 
>> 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(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
>>>>
>>>>
>>>
>>> -Michael
>>>
>> Best regards,
>> Timmothy Wilson
> 
> -Michael
> 
Best regards,
Timmothy Wilson



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]