https://bz.apache.org/bugzilla/show_bug.cgi?id=60182
--- Comment #1 from gmoni...@gmail.com --- This behaviour in Apache 2.4 is still ongoing in trunk and it is making it very difficult for server operators. On the one hand authorities like the Dutch NCSC and privacy focused customers are demanding that OCSP stapling should be enabled, and at the other hand you have a bug in the Apache code that makes it nearly impossible to have stapling enabled while an OCSP responder is unreachable with no immediate connection refusal. The OCSP responders and the browser clients are completely outside the operators control. Setting FakeTryLater or leaving it on default would really help in this case, because the ResponderTimeOut is only experienced on one TLS connection setup by a client and then the TryLater is cached. However this is not possible for two reasons: 1. The TryLater if it is made by Apache 2.4 is not marked as an unsuccesful response, so it is cached for the duration of the succesful OCSP response caching time out, which you would want to be long. So, this will mean that even a short unreachability of the OCSP responder, causes a long unavailability of the OCSP staple. Setting FakeTryLater to off, is not a real option either because then each new TLS connection from a browser will again have to suffer the ResponderTimeOut until the server can finally reach the OCSP responder, leading to a potentially huge increase in memory usage and slow website loading. 2. The faked TryLater because it is not marked as an unsuccesful response is served to the clients, even if ReturnResponderErrors is off. In itself this does not violate any RFC and the RFC meaning of TryLater would seem to support this usage. But it is contrary to the expectation from the documentation, and the natural language interpretation of ReturnReponderErrors. Also it specifically causes trouble for FireFox users. If the Firefox browser in default settings (for the past four year anyway) doesn't have a cached OCSP response itself and receives a TryLater, then it will refuse to load the site and give its users an incomprehensible message. This is not Apache's fault, but it is kind of difficult for the server operator to explain to customers. So, for the server operator at the moment, it is kind of repulsive to activate OCSP stapling in Apache. Apache turns a DOS of the OCSP responder into a DOS of the website it serves. And the fix would really be very simple. It is even already made in the 2.5 branch. Just mark the faked up TryLater as an unsuccesful response. Include *pok = false after the create of the TryLater, just as in https://github.com/apache/httpd/commit/3bd26f8c6b3ed892e0e27747bb5fce1db360ffc1#diff-f4dcc9abff3ef58debc5e15da139ce3d Then setting ReturnResponderErrors to off works also for the faked TryLater and just gives no staple response then, which is just fine for all the major browsers, as long as they are not set to require a mandatory OCSP response, which is not their default setting. Furthermore the faked TryLater is only stored for SSLStaplingErrorCacheTimeout, which increases the time a valid OCSP response staple can be available. And no TLS connections have to wait for SSLStaplingResponderTimeout seconds, but one in each error cache timeout. With that fix, I believe setting ReturnResponderErrors to on is still a bit impossible, because it turns an OCSP responder DOS unnecesarily into a website DOS. But thats a different issue, and at least as operator you have one workable configuration, even if it is not the default one. 1. Online Certificate Status Protocol - OCSP https://tools.ietf.org/html/rfc6960 2. Dutch governmental TLS guidelines, saying you have to activate OCSP stapling on the server or give a very good reason why not: https://www.ncsc.nl/binaries/ncsc/documenten/publicaties/2019/mei/01/ict-beveiligingsrichtlijnen-voor-transport-layer-security-tls/ICT-beveiligingsrichtlijnen-voor-Transport-Layer-Security-v2.pdf -- 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