feat: support tls client hello bytes callback in Kestrel

[DeagleGross]

Supporting TLS Client Hello callback in Kestrel

HTTP.SYS contribution was done in this PR

Description

Adding a new property to HttpsConnectionAdapterOptions - TlsClientHelloBytesCallback (added to public API).
It allows to subscribe to the TLS client hello message parsed from the ConnectionContext.Transport.Input:

options.TlsClientHelloBytesCallback = (connection, clientHelloBytes) =>
{
    Logger.LogDebug("[Received TlsClientHelloBytesCallback] Connection: {0}; TLS client hello buffer: {1}", connection.ConnectionId, clientHelloBytes.Length);
};

If property HttpsConnectionAdapterOptions.TlsClientHelloBytesCallback is set (not null), then new middleware is added before HttpsConnectionMiddleware.

The implementation is doing the following:

1. waiting for data to come
2. if there is enough data, try to parse TLS and determine if we need to invoke a callback
3. if there is not enough data, we either wait (not end of the stream) or simply continue the middleware pipeline

Fixes #60805

[gfoidl]

LGTM -- just a small comment.

[BrennanConroy]

Need to add this for the other UseHttps overload at the bottom of the file?

[DeagleGross]

I think it has a different use case (allows setup via TlsHandshakeCallbackOptions), but I added a check if (listenOptions.HttpsOptions?.TlsClientHelloBytesCallback is not null)

Configure Kestrel to use HTTPS. This does not use default certificates or other defaults specified via config or
KestrelServerOptions.ConfigureHttpsDefaults(Action)

[BrennanConroy]

This does not use default certificates or other defaults specified via config or
KestrelServerOptions.ConfigureHttpsDefaults(Action)

Probably shouldn't add it then.

[BrennanConroy]

But it does raise the question about client hello in that case. It also shows we have a client hello API already (although not very good) https://source.dot.net/#Microsoft.AspNetCore.Server.Kestrel.Core/TlsHandshakeCallbackContext.cs,97120719b6888c33,references

[DeagleGross]

I tried to move the callback to TlsHandshakeCallbackOptions, but it requires setting OnConnection, and I dont think it should be required for TLS client hello.

I personally would leave it where we designed it - in HttpsConnectionAdapterOptions. Let me know what you think!

(talked with @halter73 about it as well)

[DeagleGross]

Actually, I removed registration from overload using TlsHandshakeCallbackOptions, because it can result in 2 registrations of the middleware

[DeagleGross]

add tests for SSL 2.0 and SSL 3.0

[DeagleGross]

add tests for SSL 2.0 and SSL 3.0

done