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.
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
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.
mod_ssl / ssl_engine_ocsp.c customizations
Dear list, as I am new to this list, I don't know but hope questions regarding mod_ssl are welcome? I am currently working on - dirty, please have mercy - customizations of mod_ssl and especially OCSP-handling for a specific project (on basis of Apache 2.3 code). As I am neither a seasoned C-coder nor familiar with OpenSSL libraries, I am having problems extracting the issuer name from an X.509 cert into a usable string format. What I need to do: · Write my own static const char *extract_responder_uri() · Don't read responder uri from certificate, but from a file · (Responder uri is connected with the issuer of the certificate in some other place - extracted and saved to file by other means...) · File's name is equal to the issuer's DN - to my mind the most direct way to look it up · So, I have to get the issuer name from the cert and build a filename to fopen(). That's the point where I am stuck because of type problems (how to get a char* or some string from an X509_NAME?)... If this inquiry is off-topic, please give me a hint to where I could ask for help, or drop me a line, if more detail is required. Any help is highly appreciated, thanks in advance! Mit freundlichen Grüßen / Kind regards Natanael Mignon IT-Dienstleistungen: 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 eMail n...@michael-wessel.demailto:n...@michael-wessel.de webwww.michael-wessel.dehttp://www.michael-wessel.de/ Bitte senden Sie wichtige E-Mails stets auch an serv...@michael-wessel.demailto:serv...@michael-wessel.de, um sicherzustellen, dass diese zeitnah bearbeitet werden. Geschäftsführer: Michael Wessel Dipl. Phys. Amtsgericht Hannover HR B 59031
