Open Bug 300163 Opened 15 years ago Updated 8 years ago

Need APIs to set SSL session expiration timeout


(NSS :: Libraries, defect, P2)



(Not tracked)


(Reporter: julien.pierre, Assigned: nelson)



Currently, the SSL session expiration timeout for server sockets is set to the
value configured by SSL_ConfigServerSessionIDCache .

For client sockets however, the timeout appears to be hardcoded to 24 hours,
with no way for applications to change it.

If an application connects to many different SSL servers, the cache will grow
without bounds until 24 hours have elapsed.

This translates to RAM growth (which customers have misinterpreted as memory
leaks) as well as unacceptable decreased performance due to the purging
algorithm which does a linear search of all client cache sessions .

One way to avoid this problem is to limit the total client cache size. This is
the subject of bug 300343 .

Another way is to allow configuring the SSL session expiration timeout to a
shorter value for individual SSL sockets. I could not find an API to do this.

A "getter" function for the per-socket timeout value would also be nice, but not
SSL session lifetime is not a per socket variable.  SSL Sessions may be used by
potentially many sockets at once.  A session can only have one lifetime, not
separate lifetimes for each connection that uses it.  
Summary: Need APIs to set SSL session expiration timeout per socket → Need APIs to set SSL session expiration timeout
I meant that the SSL_SetSessionTimeout API should take a PRFileDesc* and change
the timeout on the SSL session that socket is using. We don't have a separate
public SSL session object .

However, we do allow extracting the session ID out of a socket with
SSL_GetSessionID as a SECItem . Maybe SSL_SetSessionTimeout should take that
SECItem ? I think it's simpler for the new API to take a PRFileDesc, because the
SSL sessions can't exist without sockets .
QA Contact: jason.m.reid → libraries
I don't propose to allow the lifetime of an existing session to be changed,
but rather I propose a way to pre-set the lifetime for NEW sessions created
by subsequent full handshakes.
Priority: -- → P2
Target Milestone: --- → 3.12
I think bug 328805 may be a duplicate of this bug.  Julien, what do you think?
Blocks: 328805
Unsetting target milestone in unresolved bugs whose targets have passed.
Target Milestone: 3.12 → ---
You need to log in before you can comment on or make changes to this bug.