Background and motivation

Currently an SslStream will reuse a session for the same target host which causes problems when you need distinct sessions for the same host. For example I've written a CredSSP authentication handler for Linux which uses an internal TLS stream to wrap the authentication tokens. This works ok when creating the first connection to a target host but if creating a second connection, say in a new thread, the server TLS implementation is unable to handle it properly causing an authentication failure.

I see there are currently three ways to avoid caching:

• Use a unique hostname, this causes issues with validating the certificate CN
• Use the env var DOTNET_SYSTEM_NET_SECURITY_DISABLETLSRESUME, this is process wide
• Use the AppContext setting System.Net.Security.DisableTlsResume, also process wide

The last two options aren't ideal due to it being process wide and it could affect unrelated code. The value of this setting is also cached so unless it was set before any SslStream was authenticated, it won't apply anymore.

API Proposal

namespace System.Net.Security;

public class SslClientAuthenticationOptions
{
    public bool DisableTlsResume { get; set; } = false;
}

Add a bool property to SslClientAuthenticationOptions that the caller can opt into for any SslStream they are going to authenticate.

This bool can then be checked at AllocateSslHandle as part of the check whether to use the cached content

API Usage

Stream stream = ...;

SslStream tls = new(stream)
SslClientAuthenticationOptions options = new()
{
    TargetHost = "target",
    DisableTlsResume = true,
};
tls.AuthenticateAsClient(options);

Alternative Designs

No response

Risks

There will most likely be a performance hit when disabling TLS resume but as this is an opt-in behaviour rather than the default it's up to the caller to justify whether this is needed.