Re: mod_ssl OCSP questions
Joe Orton wrote: Many thanks for the detailed response! Everything taken on board, with one further question: On Thu, Nov 29, 2007 at 09:35:40PM +, Dr Stephen Henson wrote: ... OpenSSL supports #1 and #2 directly so these should be automatic if the OpenSSL OCSP API has been used correctly. A limited form of #3 is implemented in OpenSSL. A generalised version might be more appropriate in some circumstances but would need additional configuration options to implement. Making the responder signature verification configurable in mod_ssl would just involve setting up a different set of trusted certs in an X509_STORE_CTX and passing that as the context parameter to OCSP_basic_verify(), right? (When you say OpenSSL supports..., I wonder if there is something more subtle here) There isn't any need to have a separate store really. A set of root CAs for different purposes can share a common store with each one given an appropriate set of trust settings. These can be edited using the OpenSSL 'x509' utility. The idea here for example is that a root CA can be labeled as trusted for client authentication or server authentication only. To retain compatibility with root CAs without trust settings most are on by default. OCSP signing is an exception which is off by default. When a root has OCSP signing trust enabled any chain leading to it can be used to sign arbitrary OCSP requests. This is a specific case of #3 where a special chain is used as a global responder which is trusted to give status information about any CA. There's some more info about this at: http://www.openssl.org/docs/apps/ocsp.html#OCSP_Response_verification_ In some cases that is too wide and restrictions on the set of CAs a given chain can authorise is more appropriate. We could in future extend the OpenSSL trust settings to authorise chains only for specific CAs (e.g. by OCSP IDs). That would probably make the need for separate per-CA configuration options in mod_ssl unnecessary. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage.
Re: randomized request for apache benchmark
I have a patch that provides this functionality to flood and will be submitting it to this list, hopefully in a day or so. Guy On Thu, 2007-11-29 at 21:45 -0600, William A. Rowe, Jr. wrote: kaby wrote: For the primarily web application is no longer static. Considering factors like cache, instruction prediction, I suppose randomized request is need to avoid possible bias in benchmark. So I wanna proposal a patch for this. Any suggestion? ab.c isn't the place for such work, and you are absolutely right (modern architectures are incredibly good at doing stupidly repetitive tasks efficiently, and this doesn't mirror the real world). Would you take a look at http://svn.apache.org/repos/asf/httpd/test/trunk/flood/ which is already moving in the direction of flexibility you seek, and is actively soliciting new ideas and patches? Bill -- Guy Ferraiolo mailto:[EMAIL PROTECTED] Performance Measurement Analysis http://CNET.com CNETtel: 1.908.541.3739 1200 Route 22 East fax: 1.908.575.7474 Bridgewater, NJ 08807 cel: 1.732.618.0250
Re: mod_ssl OCSP questions
Many thanks for the detailed response! Everything taken on board, with one further question: On Thu, Nov 29, 2007 at 09:35:40PM +, Dr Stephen Henson wrote: ... OpenSSL supports #1 and #2 directly so these should be automatic if the OpenSSL OCSP API has been used correctly. A limited form of #3 is implemented in OpenSSL. A generalised version might be more appropriate in some circumstances but would need additional configuration options to implement. Making the responder signature verification configurable in mod_ssl would just involve setting up a different set of trusted certs in an X509_STORE_CTX and passing that as the context parameter to OCSP_basic_verify(), right? (When you say OpenSSL supports..., I wonder if there is something more subtle here) joe
Re: mod_ssl OCSP questions
On Fri, Nov 30, 2007 at 10:34:28AM +0100, Marc Stern wrote: To be generic, we should be able to set some options based on the cert CA, because we could use several types of certs (like when dealing with national certs from European countries). Having security policy decided based on a *regex match* against a textual representation of the issuer DN sounds pretty scary to me! So the config options that are needed currently seem to be something like this: # select whether to validate the whole chain or just the EE cert SSLOCSPValidateWholeChain flag # set maximum time skew and age for response validity period SSLOCSPResponseWindow skew-secs max-age-secs # set CA certs for response signature verification SSLOCSPResponseCAFile file SSLOCSPResponseCAPath directory These (and existing config options) could conceivably be wrapped into issuer-CA-specific containers in the configuration, like: SSLOCSPValidationPolicy issuer-cert-file SSLOCSPFoo on /SSLOCSPValidationPolicy which does some magic to allow selection of policy based on matching the EE's issuer DN against the DNs of the certs in the issuer-cert-file; but that's all blue sky stuff. joe
Re: how to append to strings...
On 11/30/07, Arturo 'Buanzo' Busleiman [EMAIL PROTECTED] wrote: I don't quite like the bucket brigades stuff (at least for input filters), but it's good enough. I am open to other ideas... All I am trying to do is read in the text element from some XML via expat. The expat parser can break up text elements into multiple pieces; I am simply looking for the best way to build the string. The text is simply a relative path that normally is going to be less then 260 bytes. What approach would you take to build this string? Sam
Re: how to append to strings...
On 11/30/07, Sam Carleton [EMAIL PROTECTED] wrote: That is exactly what I was think about! I read the article and read through the apr_buckets.h and am still seeking more info. Does anyone know if any of the existing modules use a simply bucket system to build a string as an example for me? I'd recommend that you take my learning approach: Get the Apache source, get into the modules directory, then READ CODE! :). You'll find lot sof useful stuff there. Also, you should take a look at Nick Kew's book. I don't quite like the bucket brigades stuff (at least for input filters), but it's good enough.
Re: how to append to strings...
On Nov 30, 2007 5:25 AM, Arturo 'Buanzo' Busleiman [EMAIL PROTECTED] wrote: You might be talking about bucket brigades. You can create a brigade, transform each string into a bucket, then insert/append after/before another reference bucket, etc. This will give you an idea: http://www.onlamp.com/pub/a/apache/2001/09/20/apache_2.html That is exactly what I was think about! I read the article and read through the apr_buckets.h and am still seeking more info. Does anyone know if any of the existing modules use a simply bucket system to build a string as an example for me? Sam
Re: how to append to strings...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Sam Carleton wrote: The question is: What is the correct way to append all the pieces of XML that I am going to get from expat into one string? I recall reading somewhere that Apache has a really slick way of being able to You might be talking about bucket brigades. You can create a brigade, transform each string into a bucket, then insert/append after/before another reference bucket, etc. This will give you an idea: http://www.onlamp.com/pub/a/apache/2001/09/20/apache_2.html - -- Arturo Buanzo Busleiman - Consultor Independiente en Seguridad Informatica Apoye la Musica Libre - Vote Futurabanda desde: (ver sgte. linea) http://www.frecuenciazero.com.ar/realityrock/votar.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHT+UWAlpOsGhXcE0RCt3RAJ9dd3L7qo36/65992vIir1Zpu5B2QCdF+UQ VcQupGhhwPcY+izbYtixdyk= =K32m -END PGP SIGNATURE-
Re: mod_ssl OCSP questions
Marc Stern wrote: c) Steve mentioned some responders don't accept requests with nonces. What is a sane default? Send nonces (more secure), or not (better interop). From reading the RFC it looks like mod_ssl should also be checking the validity times from the OCSP response, which would help, I guess I'll check how we are using the API. There are some OCSP helper functions in OpenSSL which check the appropriate times and allow a configurable skew for cases where clocks are inaccurately set. How much skew to allow in practice may again depend on local policy. I agree. If using a nonce, there is no need to check the date. If not, you have to specify the time delta to accept Although a nonce supporting responder avoids replay attacks I'd say we always need to check the date in case a responder fault result in it producing status information with an invalid date. I've seen real world examples where stale information was being returned by a responder. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage.
