Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of jorton@redhat.com designates
 209.132.183.28 as permitted sender)
Date: Sun, 25 Oct 2009 20:07:21 +0000
From: Joe Orton <jorton@redhat.com>
To: dev@httpd.apache.org
Subject: Re: OCSP stapling in mod_ssl - use as OCSP cache for client
	authentication
Message-ID: <20091025200721.GA20714@redhat.com>
Mail-Followup-To: dev@httpd.apache.org
References: 
 <E1EB39574EB96B45833BF0B6BE1137241E05C2AAEC@vm-w2k3s04.intranet.michael-wessel.de>
 <4AAA1C3B.9030803@oss-institute.org> <4AB094AA.9090402@rowe-clan.net>
 <4AB0DC5A.60409@oss-institute.org> <20090916124530.GA7078@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20090916124530.GA7078@redhat.com>
User-Agent: Mutt/1.5.19 (2009-01-05)
Organization: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor,
 Berkshire, SL4 1TE, United Kingdom.
  Registered in UK and Wales under Company Registration No. 03798903
  Directors: Michael Cunningham (USA), Brendan Lane (Ireland),
 Matt Parson (USA), Charlie Peters (USA)

On Wed, Sep 16, 2009 at 01:45:30PM +0100, Joe Orton wrote:
> On Wed, Sep 16, 2009 at 01:38:50PM +0100, Dr Stephen Henson wrote:
> > I may have missed something here but the OCSP stapling code doesn't appear to be
> > in trunk. The patch in:
> > 
> > https://issues.apache.org/bugzilla/show_bug.cgi?id=43822
> > 
> > doesn't apply cleanly any more, though the changes needed to get it working are
> > fairly trivial. I'm in the process of including an updated patch.
> 
> I'm working on merging this right now, your patch did apply fine, I've 
> committed the one part separately which you alude to below.

I finally got round to finishing this off, holidays and similar excuses 
now out of the way.  First of all: thanks a lot for the patch, and sorry 
it took so long to merge!

I made a few changes relative to your latest patch:

- minor syntax/style cleanups
- renamed the new C file to ssl_util_stapling.c
- updated the handling of "SSLStaplingCache" as per changes to 
  "SSLSessionCache", to allow "SSLStaplingCache default" to DTRT
- moved up the call to ssl_stapling_ex_init() so it took effect before 
  the ex_data index was used

and have two questions:

1) the use of an ex_data structure attached to the X509 * to store the 
stapling-specific state seems unnecessary.  Was there a reason why you 
did this rather than simply extending the modssl_pk_server_t structure? 
(The ex_data indices have historically been a nightmare with mod_ssl due 
to the fact that OpenSSL might get unloaded from memory during startup, 
and any cached copies of the index values outside of OpenSSL may or may 
not be reliable.  Global state == bad!)

2) the error case where there's no SSLStaplingForceURL configured and no 
responder specified in the cert - this is currently logged but no more.  
I'm wondering whether this should be an ssl_abort(); if someone enables 
stapling for a vhost but there is no responder known, it seems like that 
should be a config error?

I've done basic testing using openssl s_client/ocsp as client/responder 
such that I can see an OCSP response being passed through, but it didn't 
seem to get cached correctly which I haven't looked into further (maybe 
I broke that with my changes).

Regards, Joe