From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc3 Firefox/1.0.7 Description of problem: I have a reverse https proxy on FC1 that uses certificate based client authentication. After updating from mod_ssl-2.0.51-1.7.legacy to mod_ssl-2.0.51-1.9.legacy it started working strange / not working. Version-Release number of selected component (if applicable): mod_ssl-2.0.51-1.9.legacy How reproducible: Always Steps to Reproduce: 1. Install FC1 with apache and mod_ssl, fully update to mod_ssl-2.0.51-1.9.legacy 2. Setup a reverse ssl proxy with certificate based client authentication 3. Try accessing it and browse 2/3 pages (and compare with mod_ssl-2.0.51-1.7.legacy's results) Actual Results: error in ssl_error_log: "SSL Re-negotiation in conjunction with POST method not supported!\nhint: try SSLOptions +OptRenegotiate" and I have to select the certificate for every file (not page, pictures too). Expected Results: Should work just like mod_ssl-2.0.51-1.7.legacy was. Additional info: I do have "SSLOptions +OptRenegotiate" and it is working fine now after I downgraded to mod_ssl-2.0.51-1.7.legacy (and apache). For me a new certificate confirmation appears for every file on FireFox and some clients reported Internet Explorer saying something like "method not supported". Here's an illustration how my confs look like (not 1:1 copy-paste): ProxyPreserveHost Off # it's by default, added just to be sure SSLProxyEngine on <Location /somedir/> SSLVerifyClient require SSLVerifyDepth 2 # requires strong ciphers SSLCipherSuite HIGH:MEDIUM SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \ and %{SSL_CLIENT_VERIFY} eq "SUCCESS" \ and %{SSL_SERVER_I_DN_CN} eq "OurCompany CA" \ and .... more requirements here ... } \ ) ProxyPass https://internal.server.ip/somedir/ ProxyPassReverse https://internal.server.ip/somedir/ </Location>
This is a httpd bug that probably became apparent with the security fix. See bug #123585
Hi Doncho N. Gunchev: Fedora Legacy currently has the httpd source package and binary sub- packages (including httpd-devel, httpd-manual, and the package that you are having trouble with, mod_ssl) in testing, fixing security issues that may not be directly related with the issue you report here. These packages have not yet been released, and are in updates-testing status. You are welcome to participate in the QA process that is happening now. The process is happening in Bug 175406: <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175406>. (For more information on Fedora Legacy's QA process, please see our wiki pages about it at <http://fedoraproject.org/wiki/Legacy/QATesting.) The announcement asking for Fedora Legacy Project participants to test and comment in Bugzilla for httpd security issues can be found in the Fedora- Legacy-List archives: <http://www.redhat.com/archives/fedora-legacy-list/2006-February/date.html> with a topic something like "Fedora Legacy Test Update Notification: httpd." In that annoucement, you can find pointers to the test rpms. By downloading and testing these packages, you can discern whether or not those packages fix the issue you are reporting here for your FC1 instal- lation. If our testing packages work for you, please let us know in Bug 175406. And if they don't, please also let us know in that Bug ticket. Because if you don't, this issue may not get fixed. From looking at the issue Marc Deslauriers mentioned in Comment #1, it looks like RedHat addressed this issue in their latest updates. Bug 123585 comment #31 indicates that a similar issue was fixed in RHEL3, and Bug 170383 indicates a similar issue was fixed for RHEL 4.
Ooops, hit the wrong button, mistakenly assigning this to ncurses. This is actually an 'httpd' bug, since in Fedora Core 1, the httpd .src.rpm generates the "mod_ssl-2.0.51-1.9.legacy" binary package: $ rpm -qi mod_ssl Name : mod_ssl Relocations: (not relocateable) Version : 2.0.51 Vendor: Fedora Legacy Release : 1.9.legacy Build Date: Sat 22 Oct 2005 10:03:19 AM CDT ... Group : System Environment/Daemons Source RPM: httpd-2.0.51-1.9.legacy.src.rpm By the way, I meant to say in the above posting, "Because if you don't, the issue may not get fixed *soon*," not meaning to imply that it will never get fixed. The Legacy project depends upon our users' participation to keep us honest. So I encourage your participation, Doncho.
Created attachment 124858 [details] Patch from RHEL4 sources that may address this issue Found the attached patch (as yet untested) which may fix this issue. This patch was gleaned from RHEL 4's source rpm, at: <http://mirrors.kernel.org/redhat/redhat/linux/updates/enterprise/4AS/en/os/SRPMS/httpd-2.0.52-22.ent.src.rpm>, (as file "httpd-2.0.52-sslreneg.patch") which appears as if it is a newer version of the patch from the apache upstream Bugzilla, <http://issues.apache.org/bugzilla/attachment.cgi?id=16491>, from the apache bugzilla ticket # 12355 comment #40, by Joe Orton: <http://issues.apache.org/bugzilla/show_bug.cgi?id=12355#c40>. "Created an attachment (id=16491) backport of patch from trunk "This is a backport of the patch from the trunk which was committed to fix this issue. Any results from testing are welcome."
The attachment looks like an xorg.conf :-)
It doesn't look like a configuration file to me. It looks like a patch file which patches: (with patch argument -p1) * httpd-2.0.46/modules/ssl/ssl_engine_io.c * httpd-2.0.46/modules/ssl/ssl_engine_kernel.c * httpd-2.0.46/modules/ssl/ssl_private.h What have you been drinking, Pekka? :-)
Doncho, as you have not gotten back to us with any information or feed- back (e.g., to make a case that it is an important issue for you and others either here or in bug 175406), I am going to downgrade this to non-security severity for now, and change the status on this ticket to "NEEDINFO." There was some sentiment in that related security bug ticket that the patch(es) needed to fix this issue were intrusive and may introduce a new security issue (see Bug #175406 comment #16). Joe Orton, the Fedora and Red Hat httpd maintainer, introduced patches in bug 123585 to fix a similar problem in Red Hat Enterprise Linux's httpd. He would not have put those patches in there for Red Hat's commercial products if he felt the same way. Am not sure our team or I fully understand your scenario and the scope of the problem. Is the lack of continual prompt for a security certificate that you observed in the older httpd/mod_ssl analogous to logging on to a website with a session cookie -- that is, once the cookie is set, one doesn't need to constantly login again with each click on a new page on that website? Not being familiar with httpd source code, it is unclear to me that the patch I found and mentioned in comment #4 (attachment 124858 [details]) is sufficent to take care of the symptoms that you are observing, or if more patch-work is needed. There are numerous patches in RHEL 4's source package, and this patch may require others, but I don't know which, if any. Since I feel so uncertain about this, I am also adding Joe Orton, as a cc to this ticket in case he has any observations or hints to help us out here. I hope you don't mind, Joe. Do you have any thoughts? Doncho, if you have any further information or ideas to offer, to help us help you, please feel free to share here. If enough time goes by without further input, we may elect to close this bug. Thanks.
This is upstream bug: http://issues.apache.org/bugzilla/show_bug.cgi?id=12355 This issue may only become apparent in some configurations after the fix for CVE-2005-2700 is applied. It's not a regression, though. It *should* have been apparent always, but CVE-2005-2700 meant that access control checks were skipped in some cases. The -sslreneg patch from the RHEL/FC4 package is the best fix for this issue and I wouldn't really be worried about putting that in the Legacy package too (it might need to be rediffed for older FC's if they don't have ssl_private.h).
Thanks for your comments, Joe. Marking this "DEFER", so we can look at this issue for next httpd security vulnerability.
Fedora Legacy is now defunct. This can't be fixed.