Google Chrome reports ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY on default MVC app

[schuettecarsten]

Describe the bug

Google Chrome reports an ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY error when trying to access a default ASP.NET Core MVC app started from Visual Studio Debugger.

To Reproduce

Steps to reproduce the behavior:

1. Create a new solution using the latest ASP.NET Core MVC sample
2. Run the sample
3. Use Google Chrome to browse to http://localhost:5000, you are redirected to https://localhost:5001
4. See error

Additional context

It works using Edge or other browsers, but Chrome does not like the default settings?

[Eilon]

@shirhatti - any idea about this?

[shirhatti]

SDPY at the time (and now HTTP/2) has a list of disallowed cipher suites. The default ordering in cipher suites in Schannel meant you could end up negotiating a cipher suite that is disallowed and the client (Chrome) was forced to reject the connection.

That being said, Chrome dropped support for SPDY back in May 2016. What version of Chrome are you using?

[schuettecarsten]

Chrome is latest version 72.0.3626.121.

I am wondering why the default sample does not work correctly here. This is the startup code, nothing was changed, of course from debugger it runs in Development mode:

// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
	if (env.IsDevelopment())
	{
		app.UseDeveloperExceptionPage();
	}
	else
	{
		app.UseExceptionHandler("/Home/Error");
		// The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
		app.UseHsts();
	}

	app.UseHttpsRedirection();
	app.UseStaticFiles();
	app.UseCookiePolicy();

	app.UseMvc(routes =>
	{
		routes.MapRoute(
			name: "default",
			template: "{controller=Home}/{action=Index}/{id?}");
	});
}

I would expect that the default code for a new app should work with all latest browsers.
My dev cert is valid:

C:\Windows\System32> dotnet dev-certs https -v
A valid HTTPS certificate is already present.

Maybe it's a cipher selection problem and related to #4776?

[shirhatti]

You shouldn't need #4776. The default order should set you up for success.

What OS version are you on?

@halter73 Maybe you've seen this before?

[halter73]

This looks to me like a cypher suite disallowed by Chrome for HTTP/2 has been negotiated. Since Kestrel uses SslStream which in turn uses SChannel on Windows, the workaround is to disable weak cypher suites at the OS level.

aspnet/KestrelHttpServer#1018 (comment)

[schuettecarsten]

You shouldn't need #4776. The default order should set you up for success.
What OS version are you on?

I am on Windows 10 Enterprise, 1809 version with all latest patches installed.

This looks to me like a cypher suite disallowed by Chrome for HTTP/2 has been negotiated. Since Kestrel uses SslStream which in turn uses SChannel on Windows, the workaround is to disable weak cypher suites at the OS level.

I have downloaded IISCrypto v3.0 (latest) and set it to "Best Practices". This did not help.

[halter73]

Did you find a solution or workaround @schuettecarsten?

[schuettecarsten]

Sorry, closed accidentially while posting my comment. The issue is still there.

[Tratcher]

Or it didn't use TLS 1.2 for some reason? Did you change anything in Program.cs?

[JohnGalt1717]

I'm also getting this on a new build of a computer. I've trusted the cert and removed unsafe cyphers with iiscrypto but kestrel still causes issues.

If I use VS.net 2019 and run it debugging with IISExpress it's fine.

My guess is that the developer cert for .NET Core 3 preview 3 isn't secure and thus chrome throws this, but the developer cert that IIS Express uses IS. (both have been registered and check out according to the tools)

IIS Express had this issue a few years ago as well that had to be fixed with an update to visual studio and a reissue of the local cert.

[Tratcher]

It's likely not that the cert itself is insecure, but that it's only compatible with certain cipher suits. i.e. I don't think it works with EC cyphers. The negotiation falls back to cert compatible ciphers and apparently doesn't find one that meents HTTP/2 requirements.

@JohnGalt1717 are you also running a Win10 insiders build? Which one?

[JohnGalt1717]

@Tratcher Yes. 19H 18362.1

[Tratcher]

FYI @JohnGalt1717 we're already discussing this over at #8952

[analogrelay]

Duplicate of #8952

Closing this one.