[release/8.0] Avoid rooting X509Certificate2 in SslSessionCache

[github-actions]

Backport of #101120 to release/8.0-staging

Fixes #101090

/cc @rzikm

Customer Impact

X509Certificates imported from PFX may be temporarily stored on disk. We extended their lifetime in .NET 8.0 (see details below) and they might not be deleted by the process. For short-lived processes, it may lead to disk space exhaustion.
Reported by a large service -- operating in environment with limited disk space and short-lived processes.

Technical details

PR #79898 fixed SslStream.IsMutuallyAuthenticated property for scenarios with TLS resumed sessions -- we found out that in some older windows versions we cannot reliably query whether the resumed session used a client certificate (important information for the property to be accurate). As a workaround, we added a reference to the X509Certificate instance on the record in the internal TLS session cache, which prolongs the lifetime of the X509Certificate.

X509Certificates constructed by importing PFX certificate have their keys stored in a key file on disk. Dispose() of the certificate is implemented such that the key file is cleaned up. Keeping a reference to the certificate from TLS session cache prevents this cleanup to happen (regardless whether user properly disposed of the certificate). The key file will then outlive the process it was created in. In scenarios with many short-lived processes which do mutually-authenticated HTTPS requests with such certificates will lead to accumulation of those files, potentially exhausting disk space.

Since we don't use the value of the certificate in any part of the code, only the knowledge whether one was used or not, we can replace the cert reference by a simple bool flag which does not extend the lifetime of the certificate.

Regression

Yes, introduced in .NET 8 in PR #79898.

Testing

Verified on the provided isolated repro from the original issue #101090.
E2E verification done by reporting customer via provided private bits.

Risk

Low, the issue is well understood and the fix is small and contained to affected code path (using client certificates on Windows).

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/ncl, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

[rzikm]

Approved via email