[Bug 60182] SSLStaplingFakeTryLater Deviates From Documented Behavior of Only Being Effective When SSLStaplingReturnResponderErrors is On
https://bz.apache.org/bugzilla/show_bug.cgi?id=60182 --- Comment #11 from gmoni...@gmail.com --- So, then we have to accept that OCSP stapling in 2.4 mod_ssl is fundamentally broken? I spent some more time looking at the mod_ssl stapling code. Unfortunately this did not improve my outlook of finding a robust stapling config for 2.4. I had somewhat adopted the feeling that running with `ReturnResponderErrors off` and `FakeTryLater` would be a configuration that was nearly *good*. Just fix the sending out of a TryLater if the OCSP responder was not reachable and it stays up when the OCSP responder is blocked from answering and all clients that I know of can reach the site and actually show it to the user, unless they have set it to mandatory revocation checking and the client locally also cannot find another source of revocation info. However, I have now noticed that if you run with `ReturnResponderErrors off`, then if a OCSP responder answers with a authoritative revocation, then it is handled by the code as if it was an error that needs to be suppressed, and it stops the revocation from reaching the client. Well That means running with responder errors of, becomes pointless. If you never return a revocation, then it is completely useless. So for 2.4 mod_ssl, two things must be fixed. Not send out a faketrylater AND NOT keep perfectly good revocations from going out. And sending out responses that can't be parsed as basic OCSP responses should also be stopped. For the hosting operator with a run of the mill production server, this leaves little options. Running with `ResponderErrors off` means that cosmetically it ticks the security boxes of delivering OCSP stapling, but it will never send out revocations it received, cache an outage unnecessarily long and dupe Firefox users when the OCSP responder is blocked. Running with `ResponderErrors on` means that an OCSP responder that is blocked from responding also delivers a much less responsive website because for each new TLS connection it will try again to get an OCSP response cached. And in both settings, it will also return OCSP responses that can't be parsed by openSSL at all. So, for the moment the hosting operator with Apache can only look to external OCSP caching proxies, to have meaning OCSP stapling, until such moment that mod_md becomes available in 2.2 or higher. And incidentally, if I look at trunk, the situation is not improving. In trunk, a renewal failure will be translated into a TLS Fatal hangup. So, if you run with OCSP stapling enabled with just mod_ssl then if an OCSP responder is unreachable or produces garbage just when the cached response expired, then from that moment until an OCSP response becomes available, NO client will be able to reach the site. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 63687] High Memory usage after upgrade to 2.4.41
https://bz.apache.org/bugzilla/show_bug.cgi?id=63687 --- Comment #63 from Curtis Wilson --- Created attachment 37066 --> https://bz.apache.org/bugzilla/attachment.cgi?id=37066&action=edit Dump of thread Attahced is the dump of a thread, we also beleive we may have solved this, at least in our case and are testing this also. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 28657] mod_negotiation should not store Content-Location header as an error header
https://bz.apache.org/bugzilla/show_bug.cgi?id=28657 --- Comment #102 from Rabin Gurung --- It is a great and informative article to sharing for everyone. I like very much thank you. https://www.everesttrekkingroutes.com/ https://www.adventuremountainguide.net/ http://www.ganeshhimaltech.com/ -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 28657] mod_negotiation should not store Content-Location header as an error header
https://bz.apache.org/bugzilla/show_bug.cgi?id=28657 --- Comment #101 from Rabin Gurung --- It is a great and informative article to sharing for everyone. I like very much thank you. https://www.everesttrekkingroutes.com/activities/12-day-everest-base-camp-trek/";>Everest Base Camp Trekking, https://www.adventuremountainguide.net";>Trekking Guide in Nepal and https://www.ganeshhimaltech.com/web-designing-in-nepal";> Web Design in Nepal -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 28657] mod_negotiation should not store Content-Location header as an error header
https://bz.apache.org/bugzilla/show_bug.cgi?id=28657 Rabin Gurung changed: What|Removed |Added URL|https://sarkariresults.toda |https://www.everesttrekking |y/ |routes.com -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 60182] SSLStaplingFakeTryLater Deviates From Documented Behavior of Only Being Effective When SSLStaplingReturnResponderErrors is On
https://bz.apache.org/bugzilla/show_bug.cgi?id=60182 --- Comment #10 from Stefan Eissing --- Thanks for the testing and feedback. Happy to hear that it works for you. Apart from borrowing a time machine, there is not much we can do about LTS. The point you raise about mod_ssl returning possibly an error when the OCSP response could not be parsed (but was retrieved successfully): that seems to be a very rare case, might indicate someone tinkering or a broken OCSP responder. For this alone, I would not really change the 2.4.x implementation of mod_ssl. To address the overall weaknesses, I think investing time into the mod_md stapling is better spent. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
