Non-HTTP TLS connection middleware

[ReubenBond]

Are there any plans for a general-purpose TLS connection middleware? I'm looking to add TLS support to Orleans (which uses sockets). I saw #11109, but it's specific to HTTPS.

(Related to Bedrock / #4772)

[analogrelay]

We don't have a plan as of yet. It's certainly something we could do if there was value in it. Ideally we'd also re-base our Https logic on top of a more general-purpose TLS middleware. From what I can tell, the main thing coupling the existing middleware to HTTPS is ALPN support. We could generalize the middleware so that instead of taking options specifying the HTTP version, it could just take ALPN protocols to negotiate.

[analogrelay]

I think we can achieve this by refactoring the (internal 🎉) HttpsConnectionMiddleware like so:

• Rename to TlsConnectionMiddleware and refactor to use ALPN-specific options with no HTTP stuff
• Add a UseTls extension method and configuration.
• Keep UseHttps extension method and HttpsConnectionAdaptorOptions and have them configure the TlsConnectionMiddleware

[analogrelay]

@ReubenBond if you're passionate and excited, we'd take a PR. Otherwise we'll put it in our planning for 5.0 and see where it shakes out.

[ReubenBond]

I took a quick stab at the first point (rename, refactor), pulling the bits into our repo. We're targeting netstandard2.0 right now & there're are a bunch of issues (lack of IAsyncDisposable & PipeWriter.Create(Stream, ...), among other things). I spoke with @sergeybykov earlier and we loosely agreed on the following w.r.t our Bedrock + TLS support:

• Upgrade orleans/master to use the packages which we expect to GA alongside .NET Core 3.0 (eg, System.IO.Pipelines 4.6.0) - this means tying our 3.0 release until after Sept 23rd when .NET Core 3.0 GAs.
• Exposing connection middleware configuration so that users can insert custom transports / middleware (rather than restricting them to the inbuilt socket transports)
• Deleting most of our internal fork of Bedrock & related Kestrel pieces & running on public bedrock bits
• Finally, creating a (hopefully temporary) separate package containing a TlsConnectionMiddleware which can target netcoreapp3.0 if needed - I assume (perhaps incorrectly) that the Stream change to implement IAsyncDisposable will not be made available on netstandard2.0 / .NET Framework in general.

After your above comments we may need to update our thinking, unless someone else in the community is available to follow your steps for a general-purpose TlsConnectionMiddleware.

[davidfowl]

Putting this in 5.0