SslStream indiscriminately uses ProtocolVersion TLS Alert for handshake failures

[rzikm]

Following code

runtime/src/libraries/System.Net.Security/src/System/Net/Security/SslStream.IO.cs

Lines 341 to 345 in 49399d9

	else if (token.Failed && (_lastFrame.Header.Type == TlsContentType.Handshake || _lastFrame.Header.Type == TlsContentType.ChangeCipherSpec))
	{
	// If we failed without OS sending out alert, inject one here to be consistent across platforms.
	payload = TlsFrameHelper.CreateAlertFrame(_lastFrame.Header.Version, TlsAlertDescription.ProtocolVersion);
	}

will make sure we send out a TLS alert when handshake fails to complete, however, (at least on Windows), this leads to indiscriminately sending out ProtocolVersion alerts even for other cases of errors, such as when the two parties cannot communicate because they don't possess a common cipher/sigalg, or because an invalid message was received. This may be misleading when attempting to debug TLS handshake errors.

We should attempt to reply with an alert that most closely resembles the type of error encountered.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/ncl, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

[wfurt]

I wish we can ask schannel to do it. This was really just a quick plug to send something. We could get smarter based on error code but that may need to go to Windows PAL....?