Oh and Thawte released a whitepaper about that : http://www.thawte.com/assets/documents/whitepaper/ocsp-stapling.pdf
Hervé. On 01/31/2014 03:18 PM, Hervé COMMOWICK wrote: > 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
