Hello, Just to move this subject back up, 2 links about OCSP stapling : - https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/ - http://news.netcraft.com/archives/2013/07/19/microsoft-achieves-world-domination-in-ocsp-stapling.html
In short, support on client and server side is clearly increasing but the main goal is not reached, as OCSP remains necessary for intermediate certificate. A new RFC has been wrote to handle those remaining case : http://tools.ietf.org/html/rfc6961 Hervé. On 11/06/2012 11:08 PM, Willy Tarreau 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 ? > > Thanks for your comments and suggestions! > Willy > > -- Hervé COMMOWICK Ingénieur systèmes et réseaux. http://www.rezulteo.com by Lizeo Online Media Group <http://www.lizeo-online-media-group.com/> 42 quai Rambaud - 69002 Lyon (France) ⎮ ☎ +33 (0)4 26 99 03 77
