add initial drop of TLS parser

[wfurt]

this is port of parser from runtime with minimal changes to fit and build.

I think the biggest issue is the license.
The original code was touched by me, @krwq and tests by @stephentoub.
With that, I think there are no external contributors so it is OK to publish fork under new license. to be consistent with rest of the repo.

Alternatively we can preserve original .NET foundation license and release reverse-proxy under dual license.

Once this is resolved, I'll update this fork with missing features.

cc: @davidsh @stephentoub @krwq @samsp-msft @Tratcher @halter73

[Tratcher]

This should be added to a sample. Something simple that checks the SNI value and disallows old TLS versions. Likely here:

reverse-proxy/samples/ReverseProxy.Sample/Program.cs

Line 24 in eb38694

.ConfigureWebHostDefaults(webBuilder =>

[Tratcher]

Once this is resolved, I'll update this fork with missing features.

Does another copy of this code exist in runtime? What's the plan to keep them in sync? I have a bot we can use if the source files are expected to be identical.

[alnikola]

Style-related comments.

[wfurt]

Does another copy of this code exist in runtime? What's the plan to keep them in sync? I have a bot we can use if the source files are expected to be identical.

Yes, there is copy here and it is primarily used for diagnostic.

My current plan is to let them diverge as I think the use case is different. For example, there is no need for ReadOnlySequence or detailed ALPN processing. So I expect new features/functions here while runtime would stay simple as it is now. If there are bugs in parsing or if there are new TLS versions needing updates, we can revisit this again. The SNI code existed for 2years without any additional change.

[wfurt]

This should be added to a sample. Something simple that checks the SNI value and disallows old TLS versions.

I want to do little bit more work before hooking in. And I wanted to keep this one as close to the original so it is easier to track changes.

[wfurt]

I moved visibility back to internal per our off-line discussion. I was also wondering about few enums outside of the TlsFrameHelper class. In runtime they lived in System.Net.Security namespace and they were used in few other places. But I'm not sure if Microsoft.ReverseProxy.Utilities is right home for them here. This can be also updated later e.g. land the migration and improve it over time.

cc: @davidfowl for any additional thought.

[Tratcher]

Which enums?

[wfurt]

TlsContentType and TlsHandshakeType for example. (there are few more)

[wfurt]

For SslStream, thy represent the values from spec so I left them outside of the parser.

[Tratcher]

They seem file where you have them for now, it doesn't matter much while they're internal. We can revisit if we decide they should be public.

[Tratcher]

Unless you want to make a Utilities.Tls namespace for all of this?

[wfurt]

I fixed up the copyright and added reference per off-line discussion. I think this should be good enough for initial drop.

[halter73]

I agree it would be nice to put these in a Utilities.Tls namespace.