Bug 57121 - ocsp stapling should not pass temporary server outages to clients
Summary: ocsp stapling should not pass temporary server outages to clients
Status: NEW
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_ssl (show other bugs)
Version: 2.4.6
Hardware: All All
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-21 10:36 UTC by Björn Jacke
Modified: 2017-08-28 14:32 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Björn Jacke 2014-10-21 10:36:11 UTC
those mod_ssl oscp default values are set here:

SSLStaplingResponseMaxAge -1 (so the entries should be valid a much more than an hour)
SSLStaplingStandardCacheTimeout 3600 (so after one hour a new ocsp request is being done by mod_ssl)

not I had saw the case that after one hour mod_ssl tried to refresh the ocsp rely from the ocsp server but i see in the proxy log that the ocsp server could not be reached. Now instead of attaching the previous (still valid) ocsp reply to the server certificate to the clients it was attaching a "try later" ocsp error in the reply to the client. As a result of that the client (firefox 33 here) was displaying an error message that there is a problem with the ocsp status of the server certificate.

If mod_ssl still have an old but valid ocsp reply in the cache it should never replace that with a "try later" ocsp error. Also setting "SSLStaplingReturnResponderErrors off" is not an option because the site might have a must-staple policy defined.
Comment 1 Jeff Trawick 2014-11-22 19:43:56 UTC
SSLStaplingStandardCacheTimeout directly controls cache expiration, so once the 3600 seconds elapses the old response is no longer available.  Thus, the previous response can't be used as a fallback if the responder can't be reached after the timeout expires.

SSLStaplingResponseMaxAge is a final sanity check on a response, so it doesn't help here.

Ideally a response would be refreshed well before cache expiration, without blocking other threads (which continue to use the previously cached response), and without removing a valid entry from the cache if a temporary communication error occurs.
Comment 2 Björn Jacke 2016-11-02 11:02:46 UTC
So we still need a new parameter like "SSLStaplingRefreshTime" then. Actually this is required to get an ocsp implementation that is stable enough not to cause problems with OCSP server that don't have perfect availability or to be able to enable stapling by default one day.
Comment 3 Fabian Wenk 2017-08-28 14:32:57 UTC
Instead of adding new SSLStaplingRefreshTime, why not just use a fraction (e.g. half) of SSLStaplingStandardCacheTimeout to refresh?
But still, if it fails at refresh time, then it has to work when cache timeout is reached.

Maybe something like this could work better / be more safe:
Try to refresh at half of SSLStaplingStandardCacheTimeout, if it fails try to refresh more often, e.g. every 1/10 of SSLStaplingStandardCacheTimeout until it succeeds and then SSLStaplingStandardCacheTimeout starts again at max. Or simply just try to refresh at every 1/10 of SSLStaplingStandardCacheTimeout.

To make less requests to the CA, set default of SSLStaplingStandardCacheTimeout to 86400 (1 day), so the refresh will happen every 2.4 hours.