From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer <michael.tremer@ipfire.org> To: development@lists.ipfire.org Subject: Re: [PATCH] apache: generating unique prime numbers and forbit use of weak DH cipher suites Date: Fri, 05 Jun 2015 14:56:00 +0200 Message-ID: <1433508960.27049.8.camel@ipfire.org> In-Reply-To: <5570AB7B.5040504@web.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8016269867846857727==" List-Id: <development.lists.ipfire.org> --===============8016269867846857727== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Thu, 2015-06-04 at 21:48 +0200, IT Superhack wrote: > Hello Michael, >=20 > Michael Tremer: > > Hi, > >=20 > > 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...) > >=20 > > 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. > >=20 > > 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. > >=20 > >> 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. > >=20 > > 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. > >=20 > > 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-AES2= 56-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-SHA= 256: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-AES1= 28-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-AES2= 56-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-SHA= 256: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-S= HA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:CAMELLIA:HIGH:!DH:!LOW:!a= NULL:!eNULL:!EXPORT:!3DES:!DES:!RC4:!MD5:!PSK:!aECDH > >> SSLHonorCipherOrder on > >> SSLCertificateFile /etc/httpd/server.crt > >> SSLCertificateKeyFile /etc/httpd/server.key > >=20 > >> Sorry for my harsh words in my last mail about pseudonyms and this stuff. > >=20 > > No worries. > >=20 > >> > >> Best regards, > >> Timmothy Wilson > >=20 > > -Michael > >=20 > 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) >=20 > Best regards, > Timmothy Wilson >=20 >=20 -Michael --===============8016269867846857727== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjIKCmlRSWNCQUFC Q2dBR0JRSlZjWnhnQUFvSkVJQjU4UDl2a0FrSEJHQVAvMWVQbHZ0V0ppZmsxdEJPR21wSS9uYnUK SjRxaEM1dFZsZ01YeldTYS90Si9xVm5XNEJjcVkwbVhkMTdVemxjOVhQV2RwS1c2VkRDdXZpMGc2 MDd2Y2ZESwpJank4ZXpHRzQzbTZUaEw3V05aNENtamFYalQycnA5OUVhd1pRcFpkWThjeVl6TUlL UU83M3hpOFJvaWVFcHVlCjZhUFhqRC9UMkszdnNQN3pIMk1XRnhFcmRPWkhhV2hYZDFQemtQRHda WjVqcFdHMEZkd3JhaVhKOWtHKzZ4Rm4KLzdGdmpkWmdMc01TbWFLQmdCTHF4MDJza1U1NDFiNUh1 d2FXUmJ4anNUTDhISEVoWUhOUlBneDRiL3VLcUhITwordUZLcGRvK21jVlNTZndYYWZVL1QwTXpS dnZ0NE9DVVFFSUJtMXdmdklvWFMxUEsyOXhTbWJZU0tCc1N4R3lsCmVrUmhnRm96SVpVUVRMemgw cy9TRFZxL3YvR3d4ejVYUFpTMG01OCtUUVdlSDFBNkxQY3UzYm50dTZXNjdiWWEKR0t4dmZrYVpD SlF3NlA1bmpIdDNQZVg1Y1BCUkM3MUZBOVRzOFNuY201b2Q5bWlIVkFzOFoyRTA2QVZ3UDJFZgp4 YlVHQ3hGNHJaZWFRZmxpMG5BRVdBZ3lncmZYd3JkRVRlTjY1R25MWGh4Z2d4L2dPd0w3RFE4Kzl1 dXZQWlFHCklQSUFxNnJEdC9UcnpVS0laMFpRTG9ZTzE2TE4xK2lnSzZzbW5LRWorME9YQ3Q3REt4 cUhkL05wMGRVQitZT3oKM0xqVlRoaVh6bWZBUWxYOUVQTkRxYjkvc3c2cGlRZDI3TXhDNURZcHFQ WTZycU1nUlFCYjJsR25mQkozeG1ldgpTZHd4MFNUTDNneGdDVTQvc1JmdQo9UXRSZgotLS0tLUVO RCBQR1AgU0lHTkFUVVJFLS0tLS0K --===============8016269867846857727==--