[PATCH] SSL: ssl_stapling_valid directive

[kyprizel]

Configuration directive allow to update it less or _more_ frequently if
required.
At the moment nobody knows how often are OCSP responses updated until check
the source code b/c there is no word in documentation about it.




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

> Hello!
>
> On Mon, Jan 13, 2014 at 08:23:46PM +0400, kyprizel wrote:
>
> > > This looks like a very-very wrong way to address the problem.
> > > Instead of resolving the problem it will hide it on some requests
> > > (but not on others), making the problem harder to detect and debug.
> >
> > Once user can access the resource - he can see the warning about system
> > time problem (and other warning).
> > If he can't access it at all seeing something like "OCSP response
> invalid"
> > - he doesn't know what to do.
>
> So the correct solution will probably be to ask browser vendors
> don't follow "abort the handshake" requirement (see
> http://trac.nginx.org/nginx/ticket/425 for other reasons why it's
> a bad idea anyway) and/or inform users about possible reasons of
> the problem.  And/or to relax thisUpdate check.  And/or to ask CAs
> to provide responses with thisUpdate set somewhere in the past.
>
> Trying to update OCSP responses less frequently doesn't
> looks like a solution.  There will be periods when a response is
> fresh anyway.
>
> >
> >
> >
> > On Mon, Jan 13, 2014 at 8:12 PM, Maxim Dounin <mdounin at mdounin.ru>
> wrote:
> >
> > > Hello!
> > >
> > > On Mon, Jan 13, 2014 at 07:45:29PM +0400, kyprizel wrote:
> > >
> > > > The reason is quite easy - most responders _do_ set validity time
> equal
> > > to
> > > > 7 days and there is no reason to update the response every hour and I
> > > want
> > > > to update it more rarely.
> > > > Some do not set nextUpdate at all and 3600 can be too rarely for
> them.
> > >
> > > These reasons suggest that deriving validity times from response
> > > validity times, as suggested earlier, would be a better way to go.
> > >
> > > >
> > > >
> > > >
> > > > On Mon, Jan 13, 2014 at 7:42 PM, Maxim Dounin <mdounin at mdounin.ru>
> > > wrote:
> > > >
> > > > > Hello!
> > > > >
> > > > > On Mon, Jan 13, 2014 at 07:04:11PM +0400, kyprizel wrote:
> > > > >
> > > > > > So, you going to leave 3600 hardcoded there?
> > > > >
> > > > > Yes, unless you have some better reasons to make it
> > > > > configurable.
> > > > >
> > > > > >
> > > > > >
> > > > > > On Mon, Jan 13, 2014 at 6:51 PM, Maxim Dounin <
> mdounin at mdounin.ru>
> > > > > wrote:
> > > > > >
> > > > > > > Hello!
> > > > > > >
> > > > > > > On Mon, Jan 13, 2014 at 06:08:53PM +0400, kyprizel wrote:
> > > > > > >
> > > > > > > > "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.
> > > > > > >
> > > > > > > This looks like a very-very wrong way to address the problem.
> > > > > > > Instead of resolving the problem it will hide it on some
> requests
> > > > > > > (but not on others), making the problem harder to detect and
> debug.
> > > > > > >
> > > > > > > --
> > > > > > > Maxim Dounin
> > > > > > > http://nginx.org/
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > nginx-devel mailing list
> > > > > > > nginx-devel at nginx.org
> > > > > > > http://mailman.nginx.org/mailman/listinfo/nginx-devel
> > > > > > >
> > > > >
> > > > > > _______________________________________________
> > > > > > nginx-devel mailing list
> > > > > > nginx-devel at nginx.org
> > > > > > http://mailman.nginx.org/mailman/listinfo/nginx-devel
> > > > >
> > > > >
> > > > > --
> > > > > Maxim Dounin
> > > > > http://nginx.org/
> > > > >
> > > > > _______________________________________________
> > > > > nginx-devel mailing list
> > > > > nginx-devel at nginx.org
> > > > > http://mailman.nginx.org/mailman/listinfo/nginx-devel
> > > > >
> > >
> > > > _______________________________________________
> > > > nginx-devel mailing list
> > > > nginx-devel at nginx.org
> > > > http://mailman.nginx.org/mailman/listinfo/nginx-devel
> > >
> > >
> > > --
> > > Maxim Dounin
> > > http://nginx.org/
> > >
> > > _______________________________________________
> > > nginx-devel mailing list
> > > nginx-devel at nginx.org
> > > http://mailman.nginx.org/mailman/listinfo/nginx-devel
> > >
>
> > _______________________________________________
> > nginx-devel mailing list
> > nginx-devel at nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
>
> --
> 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/20140114/ef6eb108/attachment.html>