This patch adds provisional OCSP stapling support to mod_ssl. OCSP stapling is a technique where instead of each client connecting to a responder individually performing OCSP checks the server itself performs a single check and sends the response to multiple clients using the certificate status TLS extension. The patch requires a recent OpenSSL 0.9.8 stable snapshot or the 0.9.9-dev version. The first official release will be 0.9.8h. If OpenSSL 0.9.8 is used then the compilation option "enable-tlsext" is also required because TLS extension support is not compiled in by default in OpenSSL 0.9.8. The following configuration options are added: SSLUseStapling: enable OCSP stapling, default off. SSLStaplingResponseSkew: number of seconds tolerance when checking OCSP responses to allow for differences in clock setting, default 5 minutes. SSLStaplingMaxAge: number of seconds to keep an OSCP response overriding any notAfter date present. This is to cover two cases. If notAfter is not present according to standard updated information is immediately available, this option indicates the time such a response should be considered valid. In other cases responder responses have been know to have very long notAfter dates weeks or months in the future even though new information is available long before then. Default is to rely on notAfter time and not override. SSLStaplingResponderTimeout: number of seconds to wait for a reply from an OCSP responder. Default is 10 seconds. SSLStaplingStandardCacheTimeout: number of seconds to cache valid responses, default 60 minutes. SSLStaplingErrorCacheTimeout: number of seconds to cache invalid responses, default foo minutes. SSLStaplingReturnResponderErrors: errors in the OCSP responder (status errors and returning of expired OCSP responses) are sent back to the client when this option is set, default on. When not set no OCSP response is sent back to the client if an error is retrieved. SSLStaplingFakeTryLater: if a connection cannot be established with the responder or no response is received then this option will send the status code "tryLater" back to the client. SSLStaplingForceURL: for the responder URL to use. Normally the certificate extensions indicate the responder URL to use, this option allows it to be overridden. This can be useful in cases where an OCSP responder is behaving as a proxy for example. Default is unset. SSLStaplingMutex: mutex to use for stapling. Syntax is identical to SSLMutex option. Some notes on the implementation: The caching is performed by storing the OCSP response in an SSL_SESSION structure. This allows the standard caching mechanisms to be utilised and reduces the number of changes required. The caching of error responses is designed to be kind to the OCSP responder by not repeatedly making requests when it is not returning valid responses. The caching policy may need tweaking to handle practical cases. A new mutex is required for OCSP stapling, this is to ensure that multiple processes do not request an updated response simultaneoudly. The mutex code has been generalized to allow the addition of new mutexes. The OCSP query code uses OpenSSLs rather basic HTTP request mechanism. For the OCSP patch it has been suggested that sub requests and mod_proxy would be more efficient. However the request_rec structure is not available inside mod_ssl at the time of the OCSP query... if this can be worked around then suggestions are welcomed. Timeouts on OCSP responses are implemented using a custom BIO which makes use of APR socket I/O. If the OCSP patch is also used this code could be shared between the two. All comments welcomed.
Created attachment 21100 [details] OCSP Stapling patch
Does this patch relate to Bug 41123 and its patch?
(In reply to comment #2) > Does this patch relate to Bug 41123 and its patch? In a way this does the opposite of #41123. #41123 is to allow a *server* to determine the certificate revocations status of a *client* certificate using OCSP. This patch is to allow a *client* to retrieve a cached response of the *server* certificate status using OCSP. Normally a busy site might result in large numbers of clients all simultaneously querying a responder to determine the status of the same server certificate. This patch makes the server query the responder once and distribute the same cached response to multiple clients. This makes use of the certificate status request TLS extension which is already in use in IE7 under Vista and I believe other browsers may soon follow suit. There is some common functionality between the two patches which could be shared. They both include code to query a responder using OCSP. This version makes use of APR sockets to implement a timeout whereas #41123 doesn't.
The trunk mod_ssl now has: 1) session caching code factored out, and 2) generic-ish OCSP request implementation. which should simplify this patch quite a lot. Any chance the patch could be redone for trunk? I don't much like adding another mutex object type on top of APR global mutexes, it seems redundant; I'd think that extending ssl_mutex_*() to take a apr_global_mutex_t * or something similar would be sufficient, so that those functions are simple helpers around the APR global mutex. (or *possibly* extending util_mutex.c to do that might make sense).
Created attachment 22981 [details] Stapling patch
Created attachment 22982 [details] New stapling.c file.
(In reply to comment #4) > The trunk mod_ssl now has: > > 1) session caching code factored out, and > 2) generic-ish OCSP request implementation. > > which should simplify this patch quite a lot. Any chance the patch could be > redone for trunk? > > I don't much like adding another mutex object type on top of APR global > mutexes, it seems redundant; I'd think that extending ssl_mutex_*() to take a > apr_global_mutex_t * or something similar would be sufficient, so that those > functions are simple helpers around the APR global mutex. (or *possibly* > extending util_mutex.c to do that might make sense). > I've finally been able to look at this again. The two attachments are an initial (incomplete) port to the trunk, it works for testing purposes but lacks some features. The rest can be done when I've clarified what people think is the best way to go about things... The mutex code has been removed and some dummy functions to replace them for now. I can change ssl_mutex_*() to apr_global_mutex_t and some additional parameters for ssl_mutex_init() and ssl_mutex_reinit() and removal of the special case code (AP_SOCACHE_FLAG_TOTMPSAFE etc) since the mutex for stapling will always be used. The timeout option doesn't currently work. There is support for timeout in the generic-ish OCSP but it is hard coded. I could change that to take a parameter. The uri and certificate parsing code does duplicate some used in some static functions in the OCSP code (but with hard coded parameters). Again that could be removed by some generalisation. I haven't at this stage altered the session caching code. It still makes use of the SSL session cache to store OCSP responses. Would a separate cache be in order, which works in a manner similar to the SSL session cache? The requirements for the OCSP stapling cache differ from the session cache: only a small number (one per certificate) of entries of relatively small size (under 1K) will be needed but they are likely to persist for longer (several minutes).
Can you post this to dev@, Steve. I have a bunch of feedback which will kill me to type into this little box.
(In reply to comment #8) > Can you post this to dev@, Steve. I have a bunch of feedback which will kill > me to type into this little box. > OK last comments, sent to dev@ under subject "OCSP Stapling support for mod_ssl".
An updated version of the patch is included. This is now fully functional and has been tested against IE 7. The caching has been rewritten to use the session caching code instead of hacking SSL_SESSION. The mutex now follows the same scheme as ssl mutex.
Created attachment 23168 [details] Update stapling diff
Created attachment 23169 [details] Updated ssl_stapling.c file
Per mail to dev@: http://marc.info/?l=apache-httpd-dev&m=125650127120687&w=2 This is now committed to trunk: http://svn.apache.org/viewvc?rev=829619&view=rev for anybody wishing to test this stuff out, please submit feedback to dev@ and/or file new issues for any bugs found. Again, thanks to Stephen!