Bug 57131 - OCSP Stapling scalability concern
Summary: OCSP Stapling scalability concern
Status: NEW
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_ssl (show other bugs)
Version: 2.5-HEAD
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-22 15:32 UTC by Jeff Trawick
Modified: 2015-05-23 13:15 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff Trawick 2014-10-22 15:32:42 UTC
This is essentially the global stapling mutex and the work which requires holding that mutex during a handshake.

All handshakes are blocked during any stapling activity for any server/certificate, including checking the cache for an OCSP response but also for accessing a responder over the network.

Slow responders holding up all handshakes could necessitate awkward attempts to configure various timeouts to try to work around the problem, such as trying to make the timeout small enough to avoid a mini-outage but large enough to handle delays commonly encountered with that responder.

mod_ssl shouldn't block handshakes for certificates for which it has a fresh-enough response to give to the client.

It would definitely be helpful to be able to obtain an existing, valid response (the normal case) with near-zero overhead.

It would definitely be helpful to prefetch responses in a daemon process/thread well before expiration.

It may be helpful to return a "tryLater" response if an existing response has expired and a query is currently being performed for the selected certificate.

This issue is at least somewhat related to issue 57121.
Comment 1 Jeff Trawick 2015-05-23 13:15:09 UTC
As of httpd 2.4.13, this part of the original description is resolved:

------------------
All handshakes are blocked during any stapling activity for any server/certificate, including checking the cache for an OCSP response but also for accessing a responder over the network.

Slow responders holding up all handshakes could necessitate awkward attempts to configure various timeouts to try to work around the problem, such as trying to make the timeout small enough to avoid a mini-outage but large enough to handle delays commonly encountered with that responder.

mod_ssl shouldn't block handshakes for certificates for which it has a fresh-enough response to give to the client.

It would definitely be helpful to be able to obtain an existing, valid response (the normal case) with near-zero overhead.
-------------------

The issue remains open post-2.4.13 as there is still a scalability concern as larger and larger numbers of certificates are handled by the same server (or some responder is slow): Only one refresh can be done at a time, all handshakes needing a refreshed OCSP response are blocked.