A few days ago, I read about a security hole in the diffie-hellman-algorithm here: http://www.heise.de/security/meldung/Logjam-Attacke-Verschluesselung-von-zehntausenden-Servern-gefaehrdet-2657502.html As they said, there are two steps to fix the issue: (1) Do not use the DHE_EXPORT cipher suites (2) Do not use default pirmary numbers Currently, the Apache Webserver is vulnerable to both points. Please see http://forum.ipfire.org/viewtopic.php?f=41&t=13612&p=85404p85404 for details.
(In reply to Timmothy Wilson from comment #0) > As they said, there are two steps to fix the issue: > (1) Do not use the DHE_EXPORT cipher suites We do not allow using the EXPORT cipher suites. So I guess this is resolved then?
(In reply to Michael Tremer from comment #1) > (In reply to Timmothy Wilson from comment #0) > > As they said, there are two steps to fix the issue: > > (1) Do not use the DHE_EXPORT cipher suites > > We do not allow using the EXPORT cipher suites. So I guess this is resolved > then? According to https://weakdh.org/sysadmin.html and the screenshots I made in the forum post, your answer is wrong. The problem is not with the EXPORT cipher suites, but - as I understood - with some DH suits which provide security equal to 1024 RSA keys. Second, the Apache Webserver still uses common prime numbers, which are insecure. To fix this, some individual prime numbers needs to be generated (see the link for more details, I'm afraid I didn't explained it well). I will add changed versions of the Apache configuration files and the "httpscert" script.
Created attachment 353 [details] Patched version of /etc/httpd/vhosts.d/ipfire-interface-ssl.conf
Created attachment 354 [details] Patched version of /usr/local/bin/httpscert
Created attachment 355 [details] Updated version of /usr/local/bin/httpscert Sorry, I was working with old files. Updated the httpscert script to the current file in git, which includes the SHA256 patch. Please use this version instead of the previous one.
As far I was able to make out what has been changed in these files, it looks fine. I would be very much interested in having an individual DH param on every IPFire machine. Could you please format the patch as it is described here (http://wiki.ipfire.org/devel/git/commit-messages) and send it to the development mailing list as described here (http://wiki.ipfire.org/devel/submit-patches)?
Hello Michael, I have done researches to this issue. There are "only" two solutions: - Upgrade to Apache 2.4.7 or higher because Apache 2.2.x doesn't support DH params bigger than 1024 bits. - Disable "DH" and permit "ECDHE" mode only (this may cause problems, as you told me on the mailing list a while ago...) Needless to say, IPFire could also use ECDSA keys instead of RSA (ECDSA is faster and provides more security; I'll fill that in another bug...). Because with ECDSA keys, ECDHE is the only key exchange method which makes sense. Best regards, Timmothy Wilson
(In reply to Timmothy Wilson from comment #7) > There are "only" two solutions: > - Upgrade to Apache 2.4.7 or higher because Apache 2.2.x doesn't support DH > params bigger than 1024 bits. I would be happy to accept a patch for this but I don't have the time to work on this myself. > - Disable "DH" and permit "ECDHE" mode only (this may cause problems, as you > told me on the mailing list a while ago...) This an option that we cannot do (unfortunately). It is technically a good one, but we also have to be compatible.
As there is nothing happening here I am closing this bug. Reopen if there is still something that needs fixing.
Since DH suites are disabled now, this issue will be fixed in Core Update 115.
This will be fixed with Core Update 115 (disabled DH suites entirely).