Blazor - integrity checks fail on firefox over non secure connection but work in chrome

[dazinator]

I have recently upgraded our asp.net core 3.1.0 hosted blazor app from blazor 3.2.0 preview 3 to 3.2.0.

We are noticing that we are gettting integritty check failures but only from Firefox. In google chrome it works fine. We have various developers all replicating the issue using clean installs of the latest version of firefox. The problem seems to be to do with the integrity check on blazor's dotnet script and we say that because thats the only script that we can see that uses a sha256 integrity check.

I noticed this issue: #22470 but it doesn't appear to cover our case because:

1. We don't push our published assets using git or kudo: Our flow is:
   • CI build is done by an Azure Devops Pipeline --> Hosted agent (latest windows) checks out code, and builds the solution and does a dotnet publish which is then uploaded as a zipped build artifact.
   • Azure DevOps "Releases" pipeline is then triggered which downloads the build artfifact, then does a DOCKER build, producing a docker image containing the published output.
   • push the docker image to ACR (Azure Container Registry)
   • deploy the image to an Azure App Service for Containers (windows) instance, - to a deployment slot.

We noticed that the site works fine in chrome (Version 83.0.4103.97 (Official Build) (64-bit))
However in latest firefox (77.0.1 (64-bit):

[javiercn]

@dazinator thanks for contacting us.

Can you tell us which file is having issues? Is it dotnet.js, blazor.wasm or any of the assemblies?

[dazinator]

@javiercn
It seems to be on the dotnet.js. Here is the firefox concole output:

14:53:45.755
GEThttp://****-pr159.azurewebsites.net/
[HTTP/1.1 304 Not Modified 222ms]

14:53:46.107
GEThttp://****-pr159.azurewebsites.net/css/app.min.css
[HTTP/1.1 304 Not Modified 84ms]

14:53:46.122
GEThttps://fonts.googleapis.com/css?family=Montserrat&display=swap
[HTTP/2 200 OK 0ms]

14:53:46.134
GEThttps://fonts.googleapis.com/css?family=Open+Sans&display=swap
[HTTP/2 200 OK 0ms]

14:53:46.160
GEThttp://****-pr159.azurewebsites.net/Scripts/clickAndPositionHandler.js
[HTTP/1.1 304 Not Modified 56ms]

14:53:46.161
GEThttps://use.fontawesome.com/releases/v5.10.2/css/all.css
[HTTP/2 200 OK 0ms]

14:53:46.177
GEThttp://****-pr159.azurewebsites.net/js/gridblazor.js
[HTTP/1.1 304 Not Modified 72ms]

14:53:46.182
GEThttp://****-pr159.azurewebsites.net/_framework/blazor.webassembly.js
[HTTP/1.1 304 Not Modified 57ms]

14:53:46.187
GEThttps://code.jquery.com/jquery-3.3.1.slim.min.js
[HTTP/1.1 200 OK 0ms]

14:53:46.225
GEThttps://cdnjs.cloudflare.com/ajax/libs/popper.js/1.14.7/umd/popper.min.js
[HTTP/2 200 OK 0ms]

14:53:46.244
GEThttps://stackpath.bootstrapcdn.com/bootstrap/4.3.1/js/bootstrap.min.js
[HTTP/2 200 OK 0ms]

14:53:46.772
GEThttps://fonts.googleapis.com/css?family=Montserrat&display=swap
[HTTP/2 200 OK 0ms]

14:53:46.787
GEThttps://fonts.googleapis.com/css?family=Open+Sans&display=swap
[HTTP/2 200 OK 0ms]

14:53:47.641
GEThttp://****-pr159.azurewebsites.net/favicon.ico
[HTTP/1.1 404 Not Found 0ms]

14:53:49.110
GEThttp://****-pr159.azurewebsites.net/_framework/wasm/dotnet.3.2.0.js
[HTTP/1.1 304 Not Modified 327ms]

14:53:51.792 None of the “sha256” hashes in the integrity attribute match the content of the subresource. ****-pr159.azurewebsites.net
14:53:51.828 TypeError: NetworkError when attempting to fetch resource.

[dazinator]

Here it is again, with caching disabled:

I have noticed that the SSL cert is not trusted by Firefox (is the standard one that azure websites uses), and GET requests are sent over http rather than https. Could that be the cause of this issue? This didn't seem to be a problem before the upgrade from preview3

[dazinator]

I can confirm that it works in Chrome, but the difference with chrome, is that even though it doesn't trust the cert, it still requests the files over HTTPS not HTTP. Firefox seems to fall back to HTTP. Not sure why this would effect the hash check in anyway, but htis is the only difference I can spot.

[javiercn]

@dazinator hmm, not sure why the cert is untrusted on Firefox, but on azurewebsites it should be. It is weird that it works on Chrome/Edge vs Firefox. Are you using a custom cert or a proxy that MiTM https traffic?

[javiercn]

This doesn't seem to be a problem with the file itself nor the hash since it works on Chrome/Edge. I would try to download the file from firefox directly and check the integrity manually.

[javiercn]

Sometimes browsers report an integrity issue when the actual cause is that the browser blocks the download or something similar. Do you have CSP enabled by any chance?

[dazinator]

@javiercn

• no content security policy is not enabled.
• no I am not using in special MITM or proxy, this is a vanilla app service (for windows containers) and here are the network settings (I have not set up any SSL cert so its using whatever azure serves up by default):

With respect to:

This doesn't seem to be a problem with the file itself nor the hash since it works on Chrome/Edge. I would try to download the file from firefox directly and check the integrity manually.

Any directions for the easiest way to do that on windows would be much appreciated!
Assuming it is valid (as it works in chrome) this would indicate a firefox bug - and this would mean it should be easy to replicate or verify on the ms side?

I did notice that chrome seems to download the files over https, where as firefox is trying to use http, and this makes me very suspcious.

[dazinator]

Here is a gist containing the dotnet script returned from firefox's GET request over http, which it then fails the integrity check on:

https://gist.github.com/dazinator/696cbd50223ab00a36c47c0fcf4598d3

Here is the equivalent which succeeds in chrome (requested over https):

https://gist.github.com/dazinator/818a4044bee1176886abe06a0d353ff7

The two files appear to be identical

[mkArtakMSFT]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we will planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[dazinator]

So as of yesterday evening - resource integrity checks magically started working in firefox against our .azurewebsites.net site and Firefox now coincendentally reports that it trusts the SSL cert there - (even though we've made no ssl changes in the interim).

I can still produce this problem locally however. Here is a screenshot showing chrome and firefox open side by side, accessing a locally running blazor wasm app over https using the default dev cert - firefox fails the integrity checks, where as chrome the site loads fine:

The only difference seems to be chrome reports the ssl connection as secure, where as firefox doesn't trust the certificate. Firefox gives me the ability to "add an exception" but this still causes the integrity checks to fail even after I add the exception.