On Tue, Nov 6, 2012 at 11:08 PM, Willy Tarreau <w...@1wt.eu> wrote: > > > I would say the periodic-request aspect of it is pretty trivial; you add a > > timer to the event loop that expires in some configurable amount of time, > > e.g. a bit before the last OCSP response expires, and you cache the result > > until it expires or a more recent result overwrites it. Given that the > > overhead of making a single OCSP request for the cert inside HAProxy is very > > low, you can easily do this every few minutes with no perceivable overhead. > > Obviously some logic re: failing requests and retrying has to be > > implemented, > > which amounts to nothing more than a formulation for how much time to wait > > until retrying again. > > I confirm that this part it clearly nothing. > > > The user should also be able to configure whether to > > deliver an expired OCSP response or none at all in the case that an upstream > > OCSP response cannot be received by the time the currently cached response > > expires. > > That's one of the points of attention, I agree. > > > A single timer and single cache slot are used for each certificate chain. > > The > > timer is reset with a new value when: > > - a request fails; in this case we need > > to use our retry/backoff algorithm to decide how long to wait before > > retrying; > > - a request succeeds; in this case we need to use our expires algorithm, > > which can be parameterized over the expiration time of the OCSP response, > > to > > decide how long to wait before trying to get a fresh response. > > Hmmm OK it's per certificate... Obviously in fact. So that probably means > some funny mechanisms to connect to various places depending on the cert > chain (eg: for those connecting via proxies, etc...). > > > One thing to keep in mind is that OCSP stapling in many libraries has (or > > had, at one point) buggy or nonexistent support for OCSP payloads containing > > multiple certificates, > > That's a very useful and interesting piece of information. > > > and a bit of research should be done prior to > > implementation to discover the current state of the world in this regard. > > I agree! > > > I believe the official word at one point was that OCSP stapling of chains > > should be accomplished by including the entire chain in the OCSP request, > > delivering that compound OCSP response via the TLS Certificate Status > > Request > > extension. > > And do you know how large this could be for average web sites ? Maybe > there is a cross-over point where doing so has a more negative impact > than letting the client check by itself ?
There might be such a point, but arguably one could let the user decide when it is reached simply by enabling/disabling OCSP stapling. Note also that it's pretty easy to imagine that each certificate could have its own OCSP stapling options, which override whatever the specified global defaults are. Running OCSP against a 3-cert chain, I get a DER-encoded response that is 1866 bytes. In a typical configuration this represents a negligible amount of caching and bandwidth overhead. > > > Thanks for your comments and suggestions! > Willy >
