HTTP/3: QuicConnectionListener supports ServerOptionsSelectionCallback

[JamesNK]

ASP.NET Core allows you to configure a callback that creates SslServerAuthenticationOptions when a TLS handshake happens. This is done using the ServerOptionsSelectionCallback delegate.

Example use:

serverOptions.ListenLocalhost(5001, listenOptions =>
{
    listenOptions.Protocols = HttpProtocols.Http3;
    listenOptions.UseHttps((SslStream stream, SslClientHelloInfo clientHelloInfo, object state, CancellationToken cancellationToken) =>
    {
        return ValueTask.FromResult((new SslServerAuthenticationOptions()));
    }, state: null);
});

Does this callback make sense with QUIC? SslStream would be null, but SslClientHelloInfo and state could still be used to customize auth options with QUIC.

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

Issue Details

---

ASP.NET Core allows you to configure a callback that creates SslServerAuthenticationOptions when a TLS handshake happens. This is done using the ServerOptionsSelectionCallback delegate.

Example use:

serverOptions.ListenLocalhost(5001, listenOptions =>
{
    listenOptions.Protocols = HttpProtocols.Http3;
    listenOptions.UseHttps((SslStream stream, SslClientHelloInfo clientHelloInfo, object state, CancellationToken cancellationToken) =>
    {
        return ValueTask.FromResult((new SslServerAuthenticationOptions()));
    }, state: null);
});

Does this callback make sense with QUIC? SslStream would be null, but SslClientHelloInfo and state could still be used to customize auth options with QUIC.

Author:	JamesNK
Assignees:	-
Labels:	area-System.Net.Security, untriaged
Milestone:	-

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

Issue Details

---

ASP.NET Core allows you to configure a callback that creates SslServerAuthenticationOptions when a TLS handshake happens. This is done using the ServerOptionsSelectionCallback delegate.

Example use:

serverOptions.ListenLocalhost(5001, listenOptions =>
{
    listenOptions.Protocols = HttpProtocols.Http3;
    listenOptions.UseHttps((SslStream stream, SslClientHelloInfo clientHelloInfo, object state, CancellationToken cancellationToken) =>
    {
        return ValueTask.FromResult((new SslServerAuthenticationOptions()));
    }, state: null);
});

Does this callback make sense with QUIC? SslStream would be null, but SslClientHelloInfo and state could still be used to customize auth options with QUIC.

Author:	JamesNK
Assignees:	-
Labels:	area-System.Net.Quic, untriaged
Milestone:	-

[karelz]

@wfurt do you have more insights here?
It looks like msquic does not support anything like this ...

[JamesNK]

I think the msquic NEW_CONNECTION event, which is already used by MsQuicListener, has the required info:

runtime/src/libraries/System.Net.Quic/src/System/Net/Quic/Implementations/MsQuic/MsQuicListener.cs

Lines 160 to 205 in 31c28fc

	private static unsafe uint NativeCallbackHandler(
	IntPtr listener,
	IntPtr context,
	ref ListenerEvent evt)
	{
	if (evt.Type != QUIC_LISTENER_EVENT.NEW_CONNECTION)
	{
	return MsQuicStatusCodes.InternalError;
	}
	State state = (State)GCHandle.FromIntPtr(context).Target!;
	SafeMsQuicConnectionHandle? connectionHandle = null;
	try
	{
	ref NewConnectionInfo connectionInfo = ref *evt.Data.NewConnection.Info;
	IPEndPoint localEndPoint = MsQuicAddressHelpers.INetToIPEndPoint(ref *(SOCKADDR_INET*)connectionInfo.LocalAddress);
	IPEndPoint remoteEndPoint = MsQuicAddressHelpers.INetToIPEndPoint(ref *(SOCKADDR_INET*)connectionInfo.RemoteAddress);
	connectionHandle = new SafeMsQuicConnectionHandle(evt.Data.NewConnection.Connection);
	uint status = MsQuicApi.Api.ConnectionSetConfigurationDelegate(connectionHandle, state.ConnectionConfiguration);
	QuicExceptionHelpers.ThrowIfFailed(status, "ConnectionSetConfiguration failed.");
	var msQuicConnection = new MsQuicConnection(localEndPoint, remoteEndPoint, connectionHandle);
	msQuicConnection.SetNegotiatedAlpn(connectionInfo.NegotiatedAlpn, connectionInfo.NegotiatedAlpnLength);
	if (!state.AcceptConnectionQueue.Writer.TryWrite(msQuicConnection))
	{
	// This handle will be cleaned up by MsQuic.
	connectionHandle.SetHandleAsInvalid();
	msQuicConnection.Dispose();
	return MsQuicStatusCodes.InternalError;
	}
	return MsQuicStatusCodes.Success;
	}
	catch (Exception ex)
	{
	// This handle will be cleaned up by MsQuic by returning InternalError.
	connectionHandle?.SetHandleAsInvalid();
	state.AcceptConnectionQueue.Writer.TryComplete(ex);
	return MsQuicStatusCodes.InternalError;
	}
	}

SslStream would be null, but the server name on SslClientHelloInfo is available from the event's NewConnectionInfo argument.

I wonder if QuicListenerOptions.SslServerAuthenticationOptions should be changed to a ServerOptionsSelectionCallback delegate that is run in the NEW_CONNECTION event. It seems better to have one way to supply the options to the listener, rather than an options property and callback property on QuicListenerOptions. If someone wants static options then they can always return the same result from the callback.

[wfurt]

I'm not sure @karelz. I think this is one of the missing parts. This will be likely more problematic IMHO as QUIC closely integrates with TLS ClientHello. When NEW_CONNECTION fires, it may be too late to too early.
I think it is good to keep it open for tracking

cc: @ManickaP

[scalablecory]

Triage: @wfurt to work with @nibanks to figure out if this works.