Re: OCSP stapling in mod_ssl - use as OCSP cache for client authentication
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
Re: OCSP stapling in mod_ssl - use as OCSP cache for client authentication
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
AW: OCSP stapling in mod_ssl - use as OCSP cache for client authentication
After some time off (off this topic, at least), I am now trying to work my way
through the stapling code and the mechanisms of caching in mod_ssl. Phew... I
had expected this to be a little more straight forward even for a non-C-guru
like me. *sigh* ;)
My favourite place to have the OCSP caching done is in ssl_engine_ocsp.c -
verify_ocsp_status(), right where an OCSP request would be created:
static int verify_ocsp_status(...)
{
[...]
/* Query response cache HERE */
ruri = determine_responder_uri(sc, cert, c, pool);
if (!ruri) {
return V_OCSP_CERTSTATUS_UNKNOWN;
}
request = create_request(ctx, cert, certID, s, pool);
[...]
The idea, inspired by your stapling code, Steve, is:
- Use SHA1 hash of cert (X509_digest(cert, EVP_sha1(), idx, NULL)) as key for
the cache.
- Query cache for entry of idx above
-_ only create and dispatch new request, if no or invalid entry
- store/update response after (new) request has been dispatched and response
has been received
- validate response (either received from cache or from connection to
responder) -- this code is present, of course, and has been further customized
already.
Is there a possibility to *not* customize a bunch of files like ssl_private.h,
ssl_scache.c, ssl_engine_init.c and so on, but have all necessary handling
placed here in ssl_engine_ocsp.c (and maybe ssl_util_ocsp.c), without messing
up?
Of course, I see the pros of a generic approach, but this is definitely only
for internal OCSP caching nothing to be communicated outside of this place.
On a more detailed level, it is the caching mechanisms that trouble me. What
needs to be done to execute caching operations?
- Define and initialize a cache - similar to SSL session cache. The actual SSL
session cache functions and structures cannot be used for this, just with a
different storage (file)?
- Define and initialize a mutex for access to this additional cache...
So, I am lacking the right way to start this up, aims being at first a quick
implementation and continued refactoring to a really well done solution
afterwards. :-/
Mit freundlichen Grüßen / Kind regards
Natanael Mignon
Von: Dr Stephen Henson [shen...@oss-institute.org]
Gesendet: Freitag, 11. September 2009 11:45
An: dev@httpd.apache.org
Betreff: Re: OCSP stapling in mod_ssl - use as OCSP cache for client
authentication
What I think you are trying to do is to include a cache for OCSP queries the
proxy itself makes which is IMHO the best solution. So instead of always
consulting the OCSP responder it instead checks the cache to see if there is a
valid OCSP response in there, if it is expired or invalid then and only then
would it renew the response by making an actual query. Doing things that way
doesn't need OCSP stapling support in the server(s).
If that's correct then you could reuse some of the OCSP response query and
caching code in the stapling patch. It implements similar functionality.
Re: OCSP stapling in mod_ssl - use as OCSP cache for client authentication
Dr Stephen Henson wrote: First comment to list in general: any comments on what needs to be done to get the OCSP stapling patch accepted? I had been under the impression, from reading the bug commentary too many times, that it was not vetting the CA chain from root to cert. It seems I misunderstood and this patch is ready for backport. Please correct us if there are any other changes required to bless this code as 'production ready'/General Availability. Bill
Re: OCSP stapling in mod_ssl - use as OCSP cache for client authentication
William A. Rowe, Jr. wrote: Dr Stephen Henson wrote: First comment to list in general: any comments on what needs to be done to get the OCSP stapling patch accepted? I had been under the impression, from reading the bug commentary too many times, that it was not vetting the CA chain from root to cert. It seems I misunderstood and this patch is ready for backport. Please correct us if there are any other changes required to bless this code as 'production ready'/General Availability. 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. 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. */ has been retained which isn't true any more. 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
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
OCSP stapling in mod_ssl - use as OCSP cache for client authentication
Hello Steve, dear list, inspired by https://issues.apache.org/bugzilla/show_bug.cgi?id=43822 (OCSP stapling support for mod_ssl) I dare asking, if this patch might solve a requirement we face at the moment: We do client authentication with certificates in Apache/mod_ssl (working as SSL-reverse-proxy) and we do require validation via OCSP. In order to avoid thousands of OCSP requests within short time, the system must provide an OCSP request cache, i.e. the situation is a little different from what the stapling patch is intended to do - but if we see Apache itself as a client, it would be fitting. On basis of Apache 2.3 (for all the OCSP handling...) we have done some customizations already (thanks for your help on openssl-users!), so including the stapling patch would be welcome. I was wondering, if you had any ideas regarding this question that could help us? I'll look at the code now and try to apply the patch. Any thoughts and help welcome. Thanks in advance! Mit freundlichen Grüßen / Kind regards Natanael Mignon IT - beraten | planen | umsetzen | betreiben __ michael-wessel.de Informationstechnologie GmbH Krausenstraße 50 30171 Hannover Germany fon (+49) 511 260 911-0 (DW -13) fax (+49) 511 318 039-9 eMailn...@michael-wessel.de web www.michael-wessel.de Geschäftsführer: Michael Wessel Dipl. Phys. Amtsgericht Hannover HR B 59031 Alle Produktnamen und Firmennamen sind ggfs. eingetragene Warenzeichen und/oder Markennamen der jeweiligen Hersteller. Angebote freibleibend, Irrtümer und Druckfehler vorbehalten. Lieferung vorbehaltlich ausreichender Selbstbelieferung. © 2009 michael-wessel.de
Re: OCSP stapling in mod_ssl - use as OCSP cache for client authentication
Natanael Mignon - michael-wessel.de wrote: Hello Steve, dear list, inspired by https://issues.apache.org/bugzilla/show_bug.cgi?id=43822 (OCSP stapling support for mod_ssl) I dare asking, if this patch might solve a requirement we face at the moment: We do client authentication with certificates in Apache/mod_ssl (working as SSL-reverse-proxy) and we do require validation via OCSP. In order to avoid thousands of OCSP requests within short time, the system must provide an OCSP request cache, i.e. the situation is a little different from what the stapling patch is intended to do - but if we see Apache itself as a client, it would be fitting. On basis of Apache 2.3 (for all the OCSP handling...) we have done some customizations already (thanks for your help on openssl-users!), so including the stapling patch would be welcome. I was wondering, if you had any ideas regarding this question that could help us? I'll look at the code now and try to apply the patch. Any thoughts and help welcome. Thanks in advance! First comment to list in general: any comments on what needs to be done to get the OCSP stapling patch accepted? I've rewritten the original version to incorporate all suggestions and answered all the queries in the report. It probably needs updating, any other issues? Now to the actual query, if I understand it correctly. That patch works in reverse to your problem. It is designed to stop thousands of OCSP requests from SSL clients connecting to an Apache server and all simultaneously slamming an OCSP responder attempting to check the status of that server certificate. One option would be to add stapling client support if you wanted to use OCSP stapling. That would however only work if the servers the proxy connected to also supported OCSP stapling. Another option would be to use a local caching OCSP responder which queries the remote responder to get an initial response and just serves that up until it needs to be renewed. What I think you are trying to do is to include a cache for OCSP queries the proxy itself makes which is IMHO the best solution. So instead of always consulting the OCSP responder it instead checks the cache to see if there is a valid OCSP response in there, if it is expired or invalid then and only then would it renew the response by making an actual query. Doing things that way doesn't need OCSP stapling support in the server(s). If that's correct then you could reuse some of the OCSP response query and caching code in the stapling patch. It implements similar functionality. Steve. -- Dr Stephen N. Henson. Senior Technical/Cryptography Advisor, Open Source Software Institute: www.oss-institute.org OpenSSL Core team: www.openssl.org
AW: OCSP stapling in mod_ssl - use as OCSP cache for client authentication
-Ursprüngliche Nachricht- Von: Dr Stephen Henson [mailto:shen...@oss-institute.org] Gesendet: Freitag, 11. September 2009 11:46 An: dev@httpd.apache.org Betreff: Re: OCSP stapling in mod_ssl - use as OCSP cache for client authentication Now to the actual query, if I understand it correctly. That patch works in reverse to your problem. It is designed to stop thousands of OCSP requests from SSL clients connecting to an Apache server and all simultaneously slamming an OCSP responder attempting to check the status of that server certificate. [NM] Right, the patch basically works reverse to our way. What I think you are trying to do is to include a cache for OCSP queries the proxy itself makes which is IMHO the best solution. So instead of always consulting the OCSP responder it instead checks the cache to see if there is a valid OCSP response in there, if it is expired or invalid then and only then would it renew the response by making an actual query. Doing things that way doesn't need OCSP stapling support in the server(s). If that's correct then you could reuse some of the OCSP response query and caching code in the stapling patch. It implements similar functionality. [NM] That's it, exactly. And I've come to the conclusion, too, that reusing some of your code for our purpose would be the best solution. Hopefully, we get it right. ;) Mit freundlichen Grüßen / Kind regards Natanael Mignon IT-Dienstleistungen: beraten | planen | umsetzen | betreiben __ fon (+49) 511 260 911-0 (DW: - 13) fax (+49) 511 318 039-9 eMail n...@michael-wessel.de webwww.michael-wessel.de Bitte senden Sie wichtige E-Mails stets auch an serv...@michael-wessel.de, um sicherzustellen, dass diese zeitnah bearbeitet werden.
Re: AW: OCSP stapling in mod_ssl - use as OCSP cache for client authentication
Natanael Mignon - michael-wessel.de wrote: -Ursprüngliche Nachricht- Von: Dr Stephen Henson [mailto:shen...@oss-institute.org] If that's correct then you could reuse some of the OCSP response query and caching code in the stapling patch. It implements similar functionality. [NM] That's it, exactly. And I've come to the conclusion, too, that reusing some of your code for our purpose would be the best solution. Hopefully, we get it right. ;) It sounds worthwhile to split the code into util_ocsp.c which can be shared by the client and the server stapling, and cache modules, eh?
