## Workaround to change default 512/1024bit DH parameters in Apache 2.2 to 2048/3072bit
##
## This has been tested with Apache httpd-2.2.29 and checked via OpenSSL 1.0.2's s_client
## => openssl s_client -connect some.host.com:443 -tls1 -msg
## ===> Server Temp Key: DH, 3072 bits
##
## No waranty is given, that this workaround really fixes the issue
1. Download latest Apache 2.2 sources (2.2.29)
2. Change into the sources directory
cd httpd-2.2.29
3. Apply the attached patch:
patch -p0 < ssl_engine_dh_c.patch
4. Change directory to "modules/ssl"
cd modules/ssl/
5. Regenerate the DH params in ssl_engine_dh.c using the (modified) embedded perl script
perl ssl_engine_dh.c
6. Wait...
7. If successfully done, change back to the root of the Apache sources
cd ../..
8. (Re-)compile Apache
9. Install the newly compiled Apache
10. Restart Apache
Done.
## Update 2015-05-20 21:33:
## If you are using FreeBSD, there is also a patch for the /usr/ports/www/apache22
## Makefile, that will take care of the patching process. Not nice, but it works.
## Update 2015-05-21 16:21:
## Ben Rubson <ben.rubson@gmail.com> suggested to use 4096 bit instead of 3072
## Updated patch by him, can be found here: http://pastebin.com/5gEW4hz9
the FreeBSD patch seems to a have a problem.
This is from my Makefile:
post-extract:# remove possible leftover .svn directories in the sources
@${FIND}${WRKSRC} -type d -name .svn -print |${XARGS}${RM} -rf
# limit grep results ...
@${FIND}${WRKSRC} -type f \( -name 'NWGNU*' -o -name '*.ds?' -o -name '*.dep' -o -name '*.mak' -o -name '*.win'\) -delete
# patch the dh params
@/usr/local/bin/curl -o /var/tmp/ssl_engine_dh_c.patch https://bitbucket.org/api/2.0/snippets/wneessen/grb8/0149fefa6cb22ef4d967433da49a60057599b67c/files/ssl_engine_dh_c.patch
@cd ${WRKSRC}&& /usr/bin/patch -p0 </var/tmp/ssl_engine_dh_c.patch
@cd ${WRKSRC}/modules/ssl &&${PERL} ssl_engine_dh.c
# make qa script happy, it complains on empty dirs even 'PORTDOCS=*' is set# use RMDIR in case upstream ever place some files into this dirs
And if I run that, it'll end up with some errors thrown by make (in poudriere)
root@freebsd1:/root # poudriere bulk -j 9_3_amd64 -p 2015Q2 -z mybuild -t www/apache22[00:00:00]====>> Creating the reference jail... done[00:00:00]====>> Mounting system devices for 9_3_amd64-2015Q2-mybuild
[00:00:00]====>> Mounting ports/packages/distfiles
[00:00:00]====>> Using packages from previously failed build
[00:00:00]====>> Mounting ccache from: /data/ccache
[00:00:00]====>> Mounting packages from: /usr/local/poudriere_data/packages/9_3_amd64-2015Q2-mybuild
[00:00:00]====>> Mounting /var/db/ports from: /usr/local/etc/poudriere.d/mybuild-options
[00:00:00]====>> Appending to make.conf: /usr/local/etc/poudriere.d/mybuild-make.conf
/etc/resolv.conf -> /usr/local/poudriere_data/.m/9_3_amd64-2015Q2-mybuild/ref/etc/resolv.conf
[00:00:00]====>> Starting jail 9_3_amd64-2015Q2-mybuild
[00:00:00]====>> Logs: /usr/local/poudriere_data/logs/bulk/9_3_amd64-2015Q2-mybuild/2015-06-10_06h04m12s
[00:00:00]====>> Loading MOVED
[00:00:00]====>> Calculating ports order and dependencies
"Makefile", line 138: Need an operator
"Makefile", line 139: Need an operator
make: fatal errors encountered -- cannot continue[00:00:00]====>> Error: Error getting PKGNAME for www/apache22
[00:00:00]====>> Error: Fatal errors encountered calculating dependencies
[00:00:00]====>> Cleaning up
Florian Heigl
It looks just fine, no idea what to do with it. btw, did you ever file a PR for it @ FreeBSD? because it should be upstreamed instead of just being on bitbucket.
Florian Heigl
Browser went TABS-shall-be-spaces when copying from the 'raw' view.
Seems to be able to build now with that change applied.
Winni Neessen
Hi Florian,
I didn't file a PR for it, as this is a rather ugly workaround. I was hoping that someone from the Apache team would write a "real" patch.
Anyhow a mail with the workaround has been sent to freebsd-security@ and from there forwarded to freebsd-ports@.
Florian Heigl
I've tested putting it in the files/ directory for the port, it works nice enough.
TBH I guess ugly workaround is acceptable when the alternative is world-wide insecurities.
Thank you for your effort, without this I'd never have gotten close to a solution. If the security->ports doesn't go anywhere, would you please leave a comment here? then i'll open a PR.
Would it not be usefull to have patches for old mod_ssl modules instead ?
compiling the complete apache with all modules could be incredible complicated and even destroy the config on used systems.
Winni Neessen
According the FreeBSD team, an official patch has been commited. This is only meant as "workaround"
HTTPSSSH
You can clone a snippet to your computer for local editing.
Learn more.
Hi,
the FreeBSD patch seems to a have a problem. This is from my Makefile:
And if I run that, it'll end up with some errors thrown by make (in poudriere)
It looks just fine, no idea what to do with it. btw, did you ever file a PR for it @ FreeBSD? because it should be upstreamed instead of just being on bitbucket.
Browser went TABS-shall-be-spaces when copying from the 'raw' view.
Seems to be able to build now with that change applied.
Hi Florian,
I didn't file a PR for it, as this is a rather ugly workaround. I was hoping that someone from the Apache team would write a "real" patch. Anyhow a mail with the workaround has been sent to freebsd-security@ and from there forwarded to freebsd-ports@.
I've tested putting it in the files/ directory for the port, it works nice enough. TBH I guess ugly workaround is acceptable when the alternative is world-wide insecurities.
Thank you for your effort, without this I'd never have gotten close to a solution. If the security->ports doesn't go anywhere, would you please leave a comment here? then i'll open a PR.
Florian
Glad it works for you. I just submitted a PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200756 let see what happens.
Would it not be usefull to have patches for old mod_ssl modules instead ? compiling the complete apache with all modules could be incredible complicated and even destroy the config on used systems.
According the FreeBSD team, an official patch has been commited. This is only meant as "workaround"