300043 - SSL client cache size should be bounded

Status: RESOLVED INACTIVE

(NSS :: Libraries, defect, P2)

Description

[Julien Pierre]

We have already seen an issue before where the SSL client-side cache would grow
apparently without bounds, because some sessions were being stored into it that
could never be restarted. Those sessions were not getting freed until the next
day, after the SSL session expired. This issue was 
https://bugzilla.mozilla.org/show_bug.cgi?id=273993 . The fix that was done was
to stop storing those useless sessions.

We now have another problem, which I discovered while coding my strsclnt
enhancements as part of bug 292151 .

Using SSL_SetSocketPeerID, it is possible to split the client cache into
different compartments. The feature is used in clients when connecting to
different hosts through a proxy for example. The problem is that the
compartments never get freed until the sessions expire, even if they are no
longer used. IMO, this is a major problem. It prevents me from using this
feature in strsclnt to resume a recent session.

But the problem isn't specific to this strsclnt case. It really applies to any
client application. Unlike the SSL server cache, the SSL client cache size isn't
limited . There is no API currently to set it upfront.

I haven't found an API to set the lifetime of client-side SSL sessions either.
If there is one, it could mitigate the problem quite a bit, since the purge
routine could take care of the issue without having to set an absolute size
limit on the client cache.

Comment 1

[Julien Pierre]

Note that in bug 292151, I experienced not only heap growth but a huge
performance drop rapidly. I believe it is due to the purging algorithm, which
examines all the client cache entries expiration time linearly for each lookup.
So, even if there is plenty of memory available, performance degrades
unreasonable because of the client cache size, and something needs to be done
about it.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

The issues here are really cache search efficiency and size bounding.
Shortening timeout times would be just a workaround.  

I agree that the size should be bounded.
It should also be made a true LRU, disarding the least recently used,
not the oldest, SID when the cache reaches a size bound.  

I agree the problem is serious enough that if affects how we implement
RFE 292151.  But I don't think this is P1 for 3.11.  
We wouldn't stop the 3.11 release for it, IMO.

Comment 3

[Julien Pierre]

I thought this bug was worthy of P1 because customers have experienced problems
related to this problem in the field that have resulted in high-visibility
escalations. This bug is a chance to work around all related issues.
I don't know if we would stop the release for it, but I would like to see this
as a high priority for an upcoming release, even if it's not necessarily 3.11 .

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

The escalated problem was bug 273993, not this bug.  It's already fixed.
The change proposed here might have further helped to mask the problem seen 
in that case, but masking application bugs is not an objective of this bug.

Comment 5

[Julien Pierre]

*** Bug 274989 has been marked as a duplicate of this bug. ***

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

remove target milestone, since the target was missed.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.