Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: softfail (athena.apache.org: transitioning domain of
 shenson@oss-institute.org does not designate 195.173.77.150 as permitted
 sender)
Message-ID: <4937C980.7020401@oss-institute.org>
Date: Thu, 04 Dec 2008 12:13:52 +0000
From: Dr Stephen Henson <shenson@oss-institute.org>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: OCSP Stapling support for mod_ssl
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

At Joe's request I've posted the last comment here. It is in reference
to bug #43822 which is OCSP Stapling support for mod_ssl:

> 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).

Steve.
-- 
Dr Stephen N. Henson. Senior Technical/Cryptography Advisor,
Open Source Software Institute: www.oss-institute.org
OpenSSL Core team: www.openssl.org