Use a unified cache for SSL_CTX objects

[rzikm]

Fixes #110803.

Regression from #102656, This also simplifies the internal code a bit and removes the requirement to always use SslStreamCertificateContext on server side to benefit from TLS Resumption.

[rzikm]

/azp run runtime-libraries-coreclr outerloop

[rzikm]

An alternative solution seems to be simply to remove

runtime/src/libraries/Common/src/Interop/Unix/System.Security.Cryptography.Native/Interop.OpenSsl.cs

Line 197 in aeda1de

handle.TryAddRentCount();

While the SslStreamCertificateContext holding the cache is gc rooted, the rent count never goes below 0 (we free when it drops below 0), and once the cert context goes out, the finalizer on SafeHandle will provide the last Dispose() which will close the handle.

Edit: the above change actually breaks a different scenario, and the code should've worked already, will try to dig more as to why it does not work now.

Edit 2: Got it, since we are using "Dispose" as "decrease reference by 1", GC finalization get's suppressed (inside SafeHandle.Dispose()) and finalizer never runs for the safe handles abandoned in the SslStreamCertificateContext. A better fix would be not using Dispose for that operation (which sounds like a good improvement in the source anyway, but after this change we won't be relying on finalizers to cleanup anymore as all reused instances are owned by the static caches)

@wfurt any opinions there? I lean towards keeping the current change (this PR), as it simplifies the code and removes the IMO not-well documented requirement on reusing cert context for TLS Resumption.

[rzikm]

/azp run runtime-libraries-coreclr outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[wfurt]

@wfurt any opinions there? I lean towards keeping the current change (this PR), as it simplifies the code and removes the IMO not-well documented requirement on reusing cert context for TLS Resumption.

I can live with ether option. Originally, I did not want global objects as the management becomes more complicated IMHO and using the context allowed easy and natural partitioning. We already use weak Certificate.Thumbprint and this change makes it more vulnerable IMHO. I do see benefit of making the resume scenario available in other cases.

While the resume behavior is not well documented (and keeps changing) I also feel the using the context is the best way and we should promote it regardless.

[rzikm]

We already use weak Certificate.Thumbprint

As of #112193, we use SHA512 which should be good for the time being.

While the resume behavior is not well documented (and keeps changing) I also feel the using the context is the best way and we should promote it regardless.

Agreed

In that case, please review this PR when you have time.