[PATCH] SSL: ssl_stapling_valid directive

[kyprizel]

"some cases", for example = you have a lot of users with wrong system time,
so they can't access the server if OCSP responses updated too frequently.
According to validity time - most responders issue OCSP response valid for
7 days, but they also can issue responses without nextUpdate option.

I think user-configurable thing is much better here b/c in most cases you
can't manipulate CA's OCSP responders options and fix them.

validity_period vs cache_valid will be better?



On Mon, Jan 13, 2014 at 5:57 PM, Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
>
> On Sat, Jan 11, 2014 at 07:52:12PM +0400, kyprizel wrote:
>
> > In some cases we need to vary period after OCSP response will be
> refreshed.
> > By default it was hardcoded to 3600 sec. This directive allows to change
> it
> > via config.
>
> In which "some cases"?  The directive was ommitted intentionally
> to simplify things as it seems to be good enough to have hardcoded
> 1h value.
>
> Note well that OCSP responses have their validity times available,
> and it may be a good idea to derive needed times from there
> instead of making things user-configurable.
>
> > Also, there were some kind of bursts when all the cluster nodes and nginx
> > workers go to update their OCSP staples - random delay within 180 sec was
> > added to fix it.
>
> This may make sense, but certainly should be a separate patch.
>
> [...]
>
> > @@ -32,6 +32,7 @@
> >      X509                        *issuer;
> >
> >      time_t                       valid;
> > +    time_t                       cache_time;
>
> I don't really like the name used.
>
> [...]
>
> > @@ -656,7 +658,11 @@
> >  done:
> >
> >      staple->loading = 0;
> > -    staple->valid = ngx_time() + 3600; /* ssl_stapling_valid */
> > +
> > +    /* ssl_stapling_valid */
> > +
> > +    staple->valid = ngx_time() + staple->cache_time
> > +                               + (ngx_random() % 180);
>
> The comment is here to indicate what the "3600" magic number
> means.  Preserving it shouldn't be needed.
>
> [...]
>
> --
> Maxim Dounin
> http://nginx.org/
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20140113/64267ab0/attachment.html>