Bug 43822 - OCSP stapling support for mod_ssl
OCSP stapling support for mod_ssl
Status: RESOLVED FIXED
Product: Apache httpd-2
Classification: Unclassified
Component: mod_ssl
2.2.6
All other
: P2 enhancement with 9 votes (vote)
: ---
Assigned To: Apache HTTPD Bugs Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2007-11-09 05:37 UTC by Dr Stephen Henson
Modified: 2014-02-17 13:49 UTC (History)
2 users (show)



Attachments
OCSP Stapling patch (51.90 KB, patch)
2007-11-09 05:39 UTC, Dr Stephen Henson
Details | Diff
Stapling patch (12.32 KB, patch)
2008-12-02 10:23 UTC, Dr Stephen Henson
Details | Diff
New stapling.c file. (17.78 KB, text/plain)
2008-12-02 10:24 UTC, Dr Stephen Henson
Details
Update stapling diff (20.49 KB, patch)
2009-01-23 10:41 UTC, Dr Stephen Henson
Details | Diff
Updated ssl_stapling.c file (21.81 KB, text/plain)
2009-01-23 10:42 UTC, Dr Stephen Henson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dr Stephen Henson 2007-11-09 05:37:01 UTC
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.
Comment 1 Dr Stephen Henson 2007-11-09 05:39:04 UTC
Created attachment 21100 [details]
OCSP Stapling patch
Comment 2 Nick Kew 2007-11-09 06:22:37 UTC
Does this patch relate to Bug 41123 and its patch?
Comment 3 Dr Stephen Henson 2007-11-09 09:19:43 UTC
(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.
Comment 4 Joe Orton 2008-04-25 09:14:04 UTC
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).
Comment 5 Dr Stephen Henson 2008-12-02 10:23:10 UTC
Created attachment 22981 [details]
Stapling patch
Comment 6 Dr Stephen Henson 2008-12-02 10:24:08 UTC
Created attachment 22982 [details]
New stapling.c file.
Comment 7 Dr Stephen Henson 2008-12-02 10:40:38 UTC
(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).


Comment 8 Joe Orton 2008-12-03 12:57:20 UTC
Can you post this to dev@, Steve.  I have a bunch of feedback which will kill me to type into this little box.
Comment 9 Dr Stephen Henson 2008-12-05 04:59:58 UTC
(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".
Comment 10 Dr Stephen Henson 2009-01-23 10:38:41 UTC
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.
Comment 11 Dr Stephen Henson 2009-01-23 10:41:45 UTC
Created attachment 23168 [details]
Update stapling diff
Comment 12 Dr Stephen Henson 2009-01-23 10:42:41 UTC
Created attachment 23169 [details]
Updated ssl_stapling.c file
Comment 13 Joe Orton 2009-10-26 14:00:06 UTC
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!