search

dotnet / aspnetcore

ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.
https://asp.net
MIT License
35.38k stars 10k forks source link

[CommandLineTools] Blazor server template example doesn't load in FF/GC due to ERR_HTTP2_INADEQUATE_TRANSPORT_SECURITY #15123

Closed ajillepalli closed 5 years ago

ajillepalli commented 5 years ago

Blazor server template example doesn't load in Firefox or Google Chrome for the non-IIS execution profile. The encountered error is along the lines of 'inadequate security' in both web browsers. A trust certificate for dotnet has been installed using the dotnet dev-certs https --trust command. Any ideas on how to best proceed? Thanks.

OS: Windows 10.0.17763 Build 17763 Error code on Firefox (v69.0.3): NS_ERROR_NET_INADEQUATE_SECURITY Error code on Google Chrome (v77.0.3865.120): ERR_HTTP2_INADEQUATE_TRANSPORT_SECURITY Both the OS and browsers are 64-bit.

Parrawk commented 5 years ago

Maybe this issue can be of help: #14350 It probably has to do with the ciphers your OS is trying to use.

The full error name would be of help and what OS you are using.

ajillepalli commented 5 years ago

Updated the original post with OS info and browser error codes, thanks.

javiercn commented 5 years ago

@ajillepalli Thanks for contacting us.

@anurse Did we update the certificate automatically?

@ajillepalli Can you run 

dotnet dev-certs https --clean
dotnet dev-certs https --trust

and see if that fixes your issue?

ajillepalli commented 5 years ago

@javiercn Cleaning and reinstalling dev-certs does not fix the issue. I'm going to check out other suggestions, as given in #14350 and report back.

analogrelay commented 5 years ago

Did you upgrade this machine from a pre-Windows 10 version of Windows? Sometimes that can mess with the cipher suite configuration. Can you run the following command (in desktop PowerShell, not PowerShell Core) and report the results?

Get-TlsCipherSuite | Format-Table Name

Also, if you could run the following bit of PowerShell to dump data about your dev cert that would help as well:

Get-ChildItem Cert:\CurrentUser\My\ | Where-Object { $_.FriendlyName.StartsWith("ASP.NET Core") } | ForEach-Object { $cert = $_; $_.Extensions | Where-Object { $_.Oid.Value -eq "1.3.6.1.4.1.311.84.1.1" } | Select-Object @{"Name"="Subject";"Expression"={$cert.Subject}},@{"Name"="Oid";"Expression"={$_.Oid.Value}},RawData }
ajillepalli commented 5 years ago

The machine runs mint Win 10, not an upgraded version.

Get-TlsCipherSuite result:

Name
----
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA

Get-ChildItem result:

Subject      Oid                    RawData
-------      ---                    -------
CN=localhost 1.3.6.1.4.1.311.84.1.1 {1}

Tried suppressing HTTPS and/or HTTPS/2, but the HTTP webpage doesn't load either. Says invalid http response.

analogrelay commented 5 years ago

Questions:

  1. Are you in a Corporate IT environment that may have affected TLS Cipher Suite configuration?
  2. Does the issue repro if you use the non-Chromium version of Edge? My hunch is that it will not because Edge uses the same TLS stack as the ASP.NET Core servers. Chromium and Firefox use their own stacks which may not honor Windows Cipher Suite names.

Looks like this is the same problem as https://github.com/aspnet/AspNetCore/issues/14350#issuecomment-542317393 . The problem is that a bunch of your cipher suites contain _Pnnn suffixes, which makes them ineligible when Google Chrome/Firefox try to negotiate TLS (since Cipher Suites are a simple string match and neither browser supports these _Pnnn suites). As a result, none of the ECDHE cipher suites are selected and the negotiation falls back to the TLS_RSA_WITH_AES suites which are explicitly blocked from HTTP/2 (causing the Inadequate Transport Security error).

Looking in more detail at the documentation for TLS Cipher Suites in Windows 10 I think I may see some of the problem. Right at the bottom it says:

Prior to Windows 10, cipher suite strings were appended with the elliptic curve to determine the curve priority. Windows 10 supports an elliptic curve priority order setting so the elliptic curve suffix is not required and is overridden by the new elliptic curve priority order, when provided, to allow organizations to use group policy to configure different versions of Windows with the same cipher suites.

I believe these priorities are the _Pnnn values. So previous versions of Windows had these values in the Cipher Suite name but Windows 10 does not (you can see this by comparing the list for Windows 10 with the list for say Windows 8.1 which has _Pnnn suffixes). Previously this seemed to be due to an update, but you are seeing this with a non-upgraded machine, which is quite strange.

In the linked issue thread, the easiest solution was to just re-set the cipher suite order to the Windows 10 value. I believe the original reporter of that issue said that as soon as he went to group policy and toggled the option from the default, it auto-filled with the correct value, so you don't need to type in the exact order as listed on the docs article.

Basically, you need to go to the Group Policy Editor too, select Computer Configuration \ Administrative Templates \ Network \ SSL Configuration Settings and choose SSL Cipher Suite Order from the list. Toggle the setting from Not Configured to Enabled and the cipher suites will auto-fill in the SSL Cipher Suites section at the bottom. Click OK and the suites are updated. It's possible a reboot is needed, but I'm not sure.

I'm going to ping some folks internally and see if we can get more information here.

ajillepalli commented 5 years ago

Thanks for your insights.

Answers:

  1. I am in a corporate IT environment. The IT environment may affect TLS Cipher Suite Config. We use Forcepoint aka Websense on our network, which maybe interfering with the default Win 10 Cipher Suite. I'll check with my IT department to confirm.
  2. As you guessed, the issue does not occur in non-Chromium version of Edge and it works well.

I applied the GPO and rebooted the system. FF/GC still have the same problem. At this point, it does seem likely that the corporate IT environment might be the problem, doesn't it?

analogrelay commented 5 years ago

I applied the GPO and rebooted the system. FF/GC still have the same problem. At this point, it does seem likely that the corporate IT environment might be the problem, doesn't it?

Hrm, that is new. In previous cases updating the GPO fixed the problem. It certainly could be the case that the corporate IT environment is still causing the problem. Could you get an updated list of TLS Cipher Suites from the PowerShell command I referred to above now that you've updated the GPO?

ajillepalli commented 5 years ago

The list of TLS Cipher Suites remain the same. All ECDHE cipher suites continue to be appended with _Pnnn string at the end.

Name
----
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
analogrelay commented 5 years ago

Could you also take a look at the registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\CipherSuites? It looks like that is another place that the Cipher Suite order could be controlled and may not show up in Group Policy.

ajillepalli commented 5 years ago

There's only one key named (Default) in the specified registry location. I edited the value field of the default key to match the values that are auto-populated by the corresponding GPO and rebooted the machine. No luck...

ajillepalli commented 5 years ago

Update: the corporate IT is indeed setting SSL suites on Windows devices.

analogrelay commented 5 years ago

Sounds like that's the root cause here. In general, that should be avoided as the corporate policy completely overrides the Windows defaults and it sounds like they haven't updated them to support HTTP/2 properly. In the interim, I'd suggest disabling HTTP/2. You can do that by adding a .ConfigureKestrel call to your WebHostBuilder calls in CreateHostBuilder:

.ConfigureKestrel((context, options) =>
{
    // Disable HTTP/2
    // If it's only your development machines that have this problem, you can wrap
    // this in `if (context.HostingEnvironment.IsDevelopment())` or some other condition
    // that is only true in development.
    listenOptions.Protocols = Microsoft.AspNetCore.Server.Kestrel.Core.HttpProtocols.Http1;
})
analogrelay commented 5 years ago

Closing as this was an issue with corporate IT policy restricting TLS Cipher Suites.

mrtristan commented 5 years ago

@anurse

might be interesting to you: chrome: works fine firefox standard: "bypassable" error in that you can go "advanced" and proceed. error code: MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT firefox dev edition: can't get past it. error code SEC_ERROR_INADEQUATE_KEY_USAGE

i'm observing this in a fresh dotnet new blazorserver on firefox dev edition but not chrome. not in a corporate environment and not on an upgraded machine (win10 pro for workstations from machine inception).

output from Get-TlsCipherSuite | Format-Table Name:

TLS_AES_256_GCM_SHA384
TLS_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_NULL_SHA256
TLS_RSA_WITH_NULL_SHA
TLS_PSK_WITH_AES_256_GCM_SHA384
TLS_PSK_WITH_AES_128_GCM_SHA256
TLS_PSK_WITH_AES_256_CBC_SHA384
TLS_PSK_WITH_AES_128_CBC_SHA256
TLS_PSK_WITH_NULL_SHA384
TLS_PSK_WITH_NULL_SHA256
analogrelay commented 5 years ago

@mrtristan Looks different to what we resolved here. I'd suggest filing a new bug. Comments on closed bugs get lost very easily :).

mrtristan commented 5 years ago

@anurse sorry to be "one of those people." not familiar enough with this domain to judge how different this situation was.

analogrelay commented 4 years ago

No worries. In general, as a repo maintainer, I'd prefer just filing new bugs and later discovering they were duplicates, so don't worry about filing a new bug even if you see a closed one that may be related!