Hello! On Fri, May 17, 2013 at 04:32:12PM -0700, Piotr Sikora wrote:
> Hey Maxim, > > > Presenting a certificate and a non-good certificate status to a > > user looks like "bees against honey" for me. I would rather not. > > While I agree that it looks kind of iffy, by not caching OCSP > responses with "revoked" or "unknown" certificate status, we're > loosing all of the OCSP stapling advantages (offloading CA's OCSP > responders, improving user's privacy and perceived performance), while > not changing anything for the user - he'll still receive exactly the > same certificate status directly from CA's OCSP responder, just a few > hundred milliseconds later. Yes, but this only happens if client actually does an OCSP request (and the user will query the same ocsp server, and response will be the same). >From site owner point of view - returning a non-good certificate status reduces probability of a client being served, and thus isn't a good idea. As this is exceptional situation - I don't think that site owner will care much about few milliseconds delay before a user sees a "bad certificate" browser's page. On the other hand, percentage of users who won't see the page (and will be able to work normally) usually matters. I understand that from a caching provider point of view this might look different though. You may consider adding a control for this, e.g., it looks like Apache has something similar called SSLStaplingReturnResponderErrors: https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslstaplingreturnrespondererrors -- Maxim Dounin http://nginx.org/en/donation.html _______________________________________________ nginx-devel mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-devel
