Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Limit OpenSSL TLS Session cache for client SSL_CTX instances #110154

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

rzikm
Copy link
Member

@rzikm rzikm commented Nov 25, 2024

This pull request limits the OpenSSL TLS Session cache for client SSL_CTX instances to 500, which should be enough for most use cases and should save some memory resources for clients.

Exceptional use cases (web scrapers?) can increase the cache size via AppCtx switch or environmental variable.

We should still investigate issues like #109600 to make sure we are not needlessly overpopulating the sessions cache.

@rzikm
Copy link
Member Author

rzikm commented Nov 25, 2024

@wfurt we've talked about this recently, so I put it up lest I forget, but this change might not be as useful once we figure out the bug causing the "leak" in the linked issue.

private const string TlsCacheSizeCtxName = "System.Net.Security.TlsCacheSize";
private const string TlsCacheSizeEnvironmentVariable = "DOTNET_SYSTEM_NET_SECURITY_TLSCACHESIZE";
private const int DefaultTlsCacheSizeClient = 500; // since we keep only one TLS Session per hostname, 500 should be enough to cover most scenarios
private const int DefaultTlsCacheSizeServer = -1; // use implementation default
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we have two different values I'm wondering if we should also split the variables...? The 500 for client seems like good default to me.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about that as well, but we either would have to

  • rename the existing configuration knob (which could be argued to be a breaking change)
  • introduce two more knobs to kontrol client/server separately
  • introduce one new with a server/client suffix and reuse the existing one for the other role

and neither of the above is a clear winner so I wanted to not complicate things needlessly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants