Fix handling SECBUFFER_EXTRA with renegotiation after handshake.

[rzikm]

Fixes #91409.

In case Renegotiation request arrives immediately after handshake, we may read it together with the ServerDone message, passing the Renegotiate message to InitializeSecurityContext would leave it unprocessed (and reported via SECBUFFER_EXTRA), but the existing code would attempt to feed it back into ISC, when the right thing to do is to pass it to DecryptMessage (as normal post-handshake data).

This PR bubbles up the amount of consumed bytes from InitializeSecurityContext and AcceptSecurityContext, so that the upper layer can decide where the extra data should go next (back to ISC/ASC if handshake is not yet finished, DecryptMessage if handshake is finished). It also adds unit tests (one of which fails without this change).

[rzikm]

/azp run runtime-libraries coreclr-outerloop

[azure-pipelines]

No pipelines are associated with this pull request.

[rzikm]

/azp run runtime-libraries-coreclr outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[rzikm]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[wfurt]

I was originally wondering if we can do something here:

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

Lines 850 to 866 in f8f4509

	extraBuffer = new byte[_buffer.DecryptedLength];
	_buffer.DecryptedSpan.CopyTo(extraBuffer);
	_buffer.Discard(_buffer.DecryptedLength);
	}
	if (NetEventSource.Log.IsEnabled())
	NetEventSource.Info(null, $"***Processing an error Status = {status}");
	if (status.ErrorCode == SecurityStatusPalErrorCode.Renegotiate)
	{
	// We determined above that we will not process it.
	if (_handshakeWaiter == null)
	{
	throw new IOException(SR.net_ssl_io_renego);
	}
	await ReplyOnReAuthenticationAsync<TIOAdapter>(extraBuffer, cancellationToken).ConfigureAwait(false);

we treat it as opaque buffer but it is probably sequence of TLS frames...?

This issue impacts only Windows IMHO so it would be nice to keep is scoped down.

[rzikm]

we treat it as opaque buffer but it is probably sequence of TLS frames...?

The Renegotiate frame which causes the problem in this case is of type Handshake, so it cannot be distinguished from the tail end of the TLS handshake (ChangeCipherSpec, Finished and such).

This issue impacts only Windows IMHO so it would be nice to keep is scoped down.

I tried to scope it down as much as possible, the Unix/OSX paths should behave the same way as before, the only change over there is the added out parameter which always reports that entire buffer passed in was processed.

I have some ideas how to refactor and simplify the Windows/Unix logic split, but I want to postpone them until early .NET 10.

[rzikm]

/azp run runtime-libraries-coreclr outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[wfurt]

LGTM