https://bz.apache.org/bugzilla/show_bug.cgi?id=57121

--- Comment #8 from [email protected] ---
Actually some of the outage issues are already changed in Apache trunk. However
if you would run the trunk version with SSLStaplingFakeTrylater off, then if
the OCSP cache runs out when the OCSP responder is out of action, then all new
TLS connections with a staple request will be hung up immediately by Apache for
the duration. I would also recommend to run it with ReturnResponderErrors Off,
to avoid shutting down some clients (only the latest trunk version after
https://github.com/apache/httpd/commit/6289dfffa43b142bed34629967a4f1a4cf051171)

The 2.4 branch is only fully usable with OCSP stapling in mod_ssl if you use a
separate caching proxy for responses.

Let me explain what happens in 2.4 (up to 41) if you run it with OCSP stapling
On and without a separate reliable OCSP cache in different settings and why I
say it is not usable in light of (inevitable) OCSP responder outages:

With ReturnResponderErrors off and FakeTryLater on, it will continue to run
when the OCSP responders are unreachable without performance problems but it
will shut out Firefox users if they have no local stored OCSP response. And
also more importantly with ReturnResponderErrors Off it will NEVER PASS ON ANY
REVOCATION MESSAGE FROM THE ORIGINAL OCSP RESPONDER. So even if it still
performant and Firefox solved their problem, then it still does NOT make any
sense to run it with ReturnResponderErrors off. Combined with FakeTryLater off
you will run into the same problem as with the ReturnResponderErrors On
setting.

If you run with ReturnResponderErrors On, then an outage of the OCSP responder
when the cache runs out, will let every new TLS connection with an OCSP staple
request hang for the duration of the Responder Timeout setting in Apache. Also
Apache request threads will have continuous contention for the
stapling_refresh_mutex.


See also:
https://bugzilla.mozilla.org/show_bug.cgi?id=1323141

-- 
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]

Reply via email to