[PATCH] OCSP stapling: better handling of successful OCSP responses.

[Maxim Dounin]

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