Re: OCSP stapling in mod_ssl - use as OCSP cache for client authentication

[Joe Orton <jo...@redhat.com>]

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.

> Nitpick: along the way I noticed the ocsp code in ssl_util_ocsp.c was updated to
> support a configurable timeout (which was in the original stapling patch) but
> the comment:
> 
> 	/* Inherit the default I/O timeout. */

Thanks for that, will fix.  Joe

Re: OCSP stapling in mod_ssl - use as OCSP cache for client authentication

[Dr Stephen Henson <sh...@oss-institute.org>]

Joe Orton wrote:
> 
> 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!
> 

Many thanks. I'm away from my test setup for a couple of days so can't test it
at present.

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

Main reason is that I'm more used to how ex_data works ;-)

As long as the cached structure is associated with each server certificate in
some way that's fine.

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

Will test it when I get back.

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

Re: OCSP stapling in mod_ssl - use as OCSP cache for client authentication

[Joe Orton <jo...@redhat.com>]

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