Default value of a session resumption timeout (300 seconds vs 7200 seconds)
Harish Kulkarni
harishvk27 at gmail.com
Thu Jan 28 17:16:39 UTC 2021
Hi,
I keep seeing growth in memory usage.. suspecting a leak. Want to disable
reference counting as well as stop caches so that i can isolate the issue.
It's all happening on client side. I will try disabling cache..
Mean while if any other inputs/pointers would be helpful.
-thanks
harish
On Wed, Jan 27, 2021 at 3:32 PM Matt Caswell <matt at openssl.org> wrote:
>
>
> On 26/01/2021 18:13, Harish Kulkarni wrote:
> > Thank you both for bringing this to my attention, your points are
> > invaluable.
> >
> > If this is something which gets set from server on client side. can
> > client override this?. Can i change this to something less and try?. Has
> > anyone tried?.
> >
> > Whats the option in openssl.conf or some other place?.
>
> The session timeout is something entirely controlled by the server. The
> client has no influence on this*. If the server is using session tickets
> for its sessions then it provides a lifetime hint to the client to say
> how long the client can expect the session to be good for. The client
> can query this using SSL_SESSION_get_ticket_lifetime_hint().
>
> On the server the timeout can be configured using SSL_CTX_set_timeout().
> I don't think this is possible to change via openssl.conf.
>
> Matt
>
>
> * Note that the client may be managing a cache of sessions provided by
> servers. That's not something that happens by default in OpenSSL but can
> be configured using SSL_CTX_set_session_cache_mode(). In that case there
> will be separate timeouts associated with the life of the session in the
> client cache. Those timeouts may not be the same as the server's timeouts.
>
> >
> > -thanks
> > harish
> >
> >
> > On Mon, Jan 25, 2021 at 11:08 PM Matt Caswell <matt at openssl.org
> > <mailto:matt at openssl.org>> wrote:
> >
> >
> >
> > On 23/01/2021 15:22, John Thoe wrote:
> > > Hi list,
> > >
> > > The session reuse question posted on the mailing list earlier
> > >
> > (
> https://mta.openssl.org/pipermail/openssl-users/2021-January/013360.html)
> > > reminded of a somewhat similar question I have.
> > >
> > > As per the docs,
> > >
> >
> https://www.openssl.org/docs/man1.0.2/man3/SSL_get_default_timeout.html,
> > > it says the default value is 300 seconds for which a session resuse
> > > will be accepted. The docs say that it is the same for all
> > > protocols.
> > >
> > > However I tried it with my setup where I didn't explicitly set the
> > > timeout and I am getting 7200 seconds as the default value.
> s_client
> > > output: TLS session ticket lifetime hint: 7200 (seconds). My client
> > > openssl.conf has no setting override (not that it should matter
> > > because this is a server preference). No OpenSSL settings on the
> > > server have been modified as well.
> >
> > Looks to me like the docs are wrong. They probably should say 7200.
> >
> >
> > >
> > > In ssl/ssl_sess.c#L80, the code matches the document: ss->timeout =
> > > 60 * 5 + 4; /* 5 minute timeout by default */ ... (with
> additional
> > > four seconds?)
> >
> >
> > This gets set during construction and then later overwritten when we
> > actually get a new session via "ssl_get_new_session":
> >
> > /* If the context has a default timeout, use it */
> > if (s->session_ctx->session_timeout == 0)
> > ss->timeout = SSL_get_default_timeout(s);
> > else
> > ss->timeout = s->session_ctx->session_timeout;
> >
> > In most cases SSL_get_default_timeout() calls tls1_default_timeout()
> (it
> > can end up somewhere different for certain protocol versions - but
> all
> > the different variants are the same!):
> >
> > long tls1_default_timeout(void)
> > {
> > /*
> > * 2 hours, the 24 hours mentioned in the TLSv1 spec is way too
> > long for
> > * http, the cache would over fill
> > */
> > return (60 * 60 * 2);
> > }
> >
> > 60 * 60 * 2 = 7200
> >
> >
> > Matt
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210128/651e6ffb/attachment-0001.html>
More information about the openssl-users
mailing list