I'm all for the idea of OCSP stapling at some point, but if this is indeed still the current state of the world, then stapling continues to be broken and probably should take lower priority to things that are not broken, e.g. client cert info passing, or less broken, e.g. OCSP checking of client certs. Here's some food for thought, though:
Mozilla talking about implementing a multiple certificate extension to OCSP stapling https://bugzilla.mozilla.org/show_bug.cgi?id=611836 Summary: Check out the first two IETF threads linked to in the discussion, and see the conclusions; these guys think that a client-side pre-fetch/caching mechanism for OCSP responses might be the way to go for now, with stapling to come later, when it is needed. Architecture-wise, I tend to agree with this, but it can nicely be combined with (a future-non-broken) OCSP stapling at the request of the client (which is already how it works), for the desired latency/roundtrip reduction. On Wed, Nov 7, 2012 at 1:42 PM, Hervé COMMOWICK <[email protected]> wrote: > As of now, on client side, it is only working on IE9 (not before not > after) and Opera, not so common... > > Look this : http://www.imperialviolet.org/2012/02/05/crlsets.html for > Google's thoughts > Short : "On this basis, we're currently planning on disabling online > revocation checks in a future version of Chrome. (There is a class of > higher-security certificate, called an EV certificate, where we haven't > made a decision about what to do yet.)" > > And this : https://bugzilla.mozilla.org/show_bug.cgi?id=360420#c10 for > Mozilla's thoughts. > Short : "it's busted by design. It can only carry a single response and > hardly any sites have only one OCSP certificate in their chain these > days. So it doesn't eliminate the OCSP lookup delay, which it's primary > attraction. > > Hervé C. > > > On 11/06/2012 11:02 PM, Willy Tarreau wrote: >> Hi Lukas, >> >> On Tue, Nov 06, 2012 at 04:57:59PM +0100, Lukas Tribus wrote: >>> >>> Don't know if it helps without some knowledge of the nginx source code, but >>> here [1] you can find the patches applied to nginx to introduce ocsp >>> support. >> >> Thanks for the pointer. Anyway as you suspect, source code alone doesn't >> tell much about the real benefits to expect from this feature, nor how >> it's supposed to be used (especially by clients). >> >>> Its doesn't seem to be trivial to implement though, because you also need to >>> run (at regular intervals) an OCSP query towards the CA's OCSP server... >> >> Amusingly, running a task at regular intervals is the easiest part to do, >> it's just like health checks. We could decide to dedicate such a task per >> stapling-enabled bind line and it would not be much of an issue. The overhead >> would not even be measurable if we were working at insane refresh rates. >> >> What's unclear to me is how many clients do support this nowadays, how many >> servers do, whether or not users are willing to allow outgoing connections >> to fetch such cert statuses, whether or not non-stapling aware clients would >> be impacted by the feature (eg: increased handshake size due to advertised >> extension and data to everyone) etc... >> >> I think we need to take more time to study this in details, but until >> someone comes with a detailed description of what this will bring to >> his site, I'm not sure anyone will spend more time on this :-/ >> >> Regards, >> 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 63 05 95 30 >
