[HTTP/3] SNI does not use the Host header value

[Tratcher]

HttpClient HTTP/3's implementation does not use HttpRequestMessage.Headers.Host for SNI, unlike prior HTTP versions.

            var request = new HttpRequestMessage(HttpMethod.Get, "https://localhost:443/");
            request.Version = HttpVersion.Version30;
            request.VersionPolicy = HttpVersionPolicy.RequestVersionExact;
            request.Headers.Host = "testhost";

Expected SNI: "testhost"
Actual SNI: "localhost"

Priority: Medium, common customer requirement, difficult to work around.

[ghost]

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

Issue Details

---

HttpClient HTTP/3's implementation does not use HttpRequestMessage.Headers.Host for SNI, unlike prior HTTP versions.

            var request = new HttpRequestMessage(HttpMethod.Get, "https://localhost:443/");
            request.Version = HttpVersion.Version30;
            request.VersionPolicy = HttpVersionPolicy.RequestVersionExact;
            request.Headers.Host = "testhost";

Expected SNI: "testhost"
Actual SNI: "localhost"

Priority: Medium, common customer requirement, difficult to work around.

Author:	Tratcher
Assignees:	-
Labels:	area-System.Net.Http
Milestone:	-

[ManickaP]

@wfurt I think there are some limitation in msquic around SNI, do I remember right?

[wfurt]

We should check if HttpClient sets ClientAuthenticationOptions.TargetHost as it should. Quic will fall-back to endpoint if not set.

[ManickaP]

Then this might be easy to fix, we might reconsider this if we have spare time.

[wfurt]

Ok. It is actually

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

Lines 573 to 592 in c97cf0c

	if (_remoteEndPoint is IPEndPoint)
	{
	SOCKADDR_INET address = MsQuicAddressHelpers.IPEndPointToINet((IPEndPoint)_remoteEndPoint);
	unsafe
	{
	Debug.Assert(!Monitor.IsEntered(_state));
	status = MsQuicApi.Api.SetParamDelegate(_state.Handle, QUIC_PARAM_LEVEL.CONNECTION, (uint)QUIC_PARAM_CONN.REMOTE_ADDRESS, (uint)sizeof(SOCKADDR_INET), (byte*)&address);
	QuicExceptionHelpers.ThrowIfFailed(status, "Failed to connect to peer.");
	}
	targetHost = _state.TargetHost ?? ((IPEndPoint)_remoteEndPoint).Address.ToString();
	port = ((IPEndPoint)_remoteEndPoint).Port;
	}
	else if (_remoteEndPoint is DnsEndPoint)
	{
	// We don't have way how to set separate SNI and name for connection at this moment.
	targetHost = ((DnsEndPoint)_remoteEndPoint).Host;
	port = ((DnsEndPoint)_remoteEndPoint).Port;
	}

Unless @nibanks has suggestion I don't know how to connect to given host but set separate SNI.
(We have fixup code if IP address is used)

[nibanks]

For MsQuic, you must pass the SNI you want in the TLS handshake in ConnectionStart.

[Tratcher]

(We have fixup code if IP address is used)

I don't see this fixup happening, I'm getting a blank SNI on the server when an IP is used. That's how I found this issue.

[wfurt]

That is not the point. In this case the host you connecting to is different than the SNI.
For IP, we set QUIC_PARAM_CONN.REMOTE_ADDRESS and pass the desired SNI to ConnectionStart @nibanks.
I don't know how to do that for name.

And It is possible HttpClient converts the IP to string and then it comes to Quc as DnsEndPoint with IP string.
I will check.

[wfurt]

runtime/src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/HttpConnectionPool.cs

Line 852 in 6ac0370

quicConnection = await ConnectHelper.ConnectQuicAsync(request, Settings._quicImplementationProvider ?? QuicImplementationProviders.Default, new DnsEndPoint(authority.IdnHost, authority.Port), _sslOptionsHttp3!, cancellationToken).ConfigureAwait(false);

So with HttpClient, we would never hit the IPEndPoint case above. I did quick PoC and we can fix it at MsQuciConnection

+ if (!string.IsNullOrEmpty(_state.TargetHost) && !dnsHost.Equals(_state.TargetHost, StringComparison.InvariantCultureIgnoreCase) && IPAddress.TryParse(((DnsEndPoint)_remoteEndPoint).Host!, out IPAddress? address))
+ {

and I can possibly fix it for cases when URI is set to address and Host header is set to different value. (_state.TargetHost)

Alternatively we would need to fix the code around HttpAuthority to pass in IPEndPoint when possible.
Not sure if that worth of the effort @Tratcher .

[Tratcher]

and I can possibly fix it for cases when URI is set to address and Host header is set to different value. (_state.TargetHost)

I think this is the primary use case, people bypassing DNS.

Eventually it should behave the same as HTTP/1.1 to avoid breaking people as they move up.

[karelz]

Triage: This will likely require API changes in msquic

[nibanks]

The design MsQuic currently has, and how HTTP.sys uses it, is that if you want to target a different IP than what the SNI points to, you'd resolve the name to whatever IP you choose and then set the remote address to that before calling ConnectionStart. We have no way to use two different host names.

[wfurt]

right, I understand this is current limitation. We can do resolution in .NET but then can we give you list of addresses? It seems suboptimal top duplicate any fall-back logic. And make it same with case when the SNI is same.

Also it seems like it would be easy to split SNI and hostanke within MsQuic and track them separately - and in common case have them same.

[ManickaP]

Triage: msquic only connects to the first IP to which the hostname resolves and doesn't do any fallbacks. Nowadays we have this fallback on the managed layer in Sockets, doing it in S.N.Quic would be equivalent to that. So we should do the resolution on our side, set remote IP in msquic, and SNI separately. No work for msquic in this, just for us.