Kestrel should disable HTTP/2 by default on downlevel windows versions

[Tratcher]

RE: #14350

HTTP/2 has two pre-requeists:
A) APLN (Win8.1+)
2) Ciphers (Win10 / 2016+)

When ALPN isn't available it gracefully falls back to HTTP/1.1. However, if ALPN is available but the correct ciphers aren't then all clients will fail to connect with the default configuration. This specifically applies to Win8.1 and 2012 R2. Win8.1 wasn't considered an issue since it has extremely low usage. We have had several reports of people using 2012 R2.

Note 2012 R2 has already exited mainstream support but is still in extended support through 2023. We'll want clarification from PMs before making changes to improve support for it.
https://support.microsoft.com/en-us/lifecycle/search?alpha=windows%20server%202012

[Tratcher]

Note we have to be careful checking versions, Environment.OSVersion does not report Win10 versions unless you enable Win10 support in the manifest. https://stackoverflow.com/a/33328814/2588374

We have a couple of options:
A) Check the registry version directly (not recommended)
B) Check Environment.OSVersion and only enable HTTP/2 if we see the correct minimum version. Apps would then have to opt in by enabling the manifest or directly setting the protocol version.
C) Do B and change the manifest by default in the templates.

Note the gRPC templates override the defaults and enable only HTTP/2. We added a mitigation on Mac to fault early because APLN support isn't available. Should we do that for 2012 R2? The difference being it might be possible to reconfigure 2012 R2 to work, it just doesn't work by default.

[jhudsoncedaron]

A) Check the registry version directly (not recommended)

Actually that's not that bad because you're explicitly checking for versions below current (Win 10).

[solrevdev]

If it helps anyone in the meantime here was my workaround: dotnet/AspNetCore.Docs#16434 (comment)

[jkotalik]

I'd imagine changing the SelectProtocol method to check Environment.OSVersion would be the right direction. https://github.com/dotnet/aspnetcore/blob/master/src/Servers/Kestrel/Core/src/Internal/HttpConnection.cs#L205

[Tratcher]

There's no need to re-compute this per connection. We have an earlier check for H2 on Mac that fails on startup. In fact, we already have a Windows OS version check there too.

aspnetcore/src/Servers/Kestrel/Core/src/Middleware/HttpsConnectionMiddleware.cs

Lines 47 to 57 in 9501874

	if (options.HttpProtocols == HttpProtocols.Http2)
	{
	if (RuntimeInformation.IsOSPlatform(OSPlatform.OSX))
	{
	throw new NotSupportedException(CoreStrings.HTTP2NoTlsOsx);
	}
	else if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows) && Environment.OSVersion.Version < new Version(6, 2))
	{
	throw new NotSupportedException(CoreStrings.HTTP2NoTlsWin7);
	}
	}

We could update this to check for Http1AndHttp2, log, and downgrade to Http1 on older versions of Windows.

[jkotalik]

Is it just me, or is it odd to have this check in HttpsConnectionMiddleware? It's odd to me that we are checking protocols there.

[jkotalik]

We have an earlier check for H2 on Mac that fails on startup. In fact, we already have a Windows OS version check there too.

Is the windows check incorrect then?

[jhudsoncedaron]

@jkotalik : It is incorrect. Environment.OSVersion was deliberately broken by the Windows OS developers. For some reason the version check can only be configured at the process level, leaving no working API that a dll can use to perform a version check.

[Tratcher]

Is it just me, or is it odd to have this check in HttpsConnectionMiddleware? It's odd to me that we are checking protocols there.

Is the windows check incorrect then?

No, it makes sense. In that case the server is configured for only Http2 and this check was making sure your platform supported ALPN which is required for H2 over TLS.

On Win8/2012R2 we have ALPN but not the ciphers we need. The proposal now is to add an additional check for Win8/2012R2 and Http1AndHttp2 that gracefully disables Http2. This allows the default configuration to work.

If you only selected Http2 and are running on Win8 should we throw? Maybe. Or maybe not because this isn't the default configuration and you had to opt into it explicitly? The ciphers can in theory be reconfigured to work, but we haven't seen people do that successfully.

@jkotalik : It is incorrect. Environment.OSVersion was deliberately broken by the Windows OS developers.

It was accurate enough for detecting Win7 and ALPN, but we'll have trouble detecting Win8. There are suggestions outlined above but they aren't pretty.

[jhudsoncedaron]

@Tratcher : You just haven't had this get hit from a custom hosting process yet, where net core itself is being hosted by a plugin to a third-party exe. No, I don't do that either, but some people write shell plugins in net core. You get arbitrarily bad compatibility manifests that way.

[Tratcher]

Environment.OSVersion was fixed for 5.0 dotnet/runtime#33651