https://bz.apache.org/bugzilla/show_bug.cgi?id=60182
--- Comment #3 from [email protected] --- @ Yann Ylavic , thanks for the suggestion. I think in most website hosting operation there is not really much use in delivering TryLater responses and probably not any of the other unsigned OCSP messages either. It is an example of Postel's principle, be conservative in what you send, do not send anything that might seem obscure. So, in those operations you just would want ReturnResponderErrors off. What could clients use an unsigned response for? Would a browser keep retrying a TLS connection to a webserver in the background if it got a TryLater and then immediately blank the site if it got a response with a retraction? In some dedicated enviroments it may be useful for Apache to be a 'true' proxy and then a TryLater seems to be semantically correct if Apache waited for a programmed timeout and couldn't reach the origin for that time, no need to consider that a 'fake' response. So, in both cases for ReturnResponderErrors, FakeTryLater should just be on. In the "off" case for it to be cached for a short while, but NOT returned, and keep the server from retrying too often, and in the "on" case to note that it couldn't provide a signed response after waiting for it. I commented on this Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1323141 to try and get that client to move, because they are just a bit too convervative on what is accepted, and together with the current Apache 2.4 behaviour this leads to unnecessary outage for their users. If there is any additional programming time, it would be nice to work on making it the *most* likely possible, that a staple can be returned. So, inspect the cache for soon to update OCSP responses and try one or several times in advance at different spacings to get a new OCSP response. That would be a security benefit. Or maybe provide a longer timeout option when a certificate has a Must-Staple attribute. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
