aspnetcore: Blazor WASM apps being blocked by firewalls due to .NET assemblies, even after renaming DLLs

During development of our current Balzor WASM application we selected some of our customers to alpha test our new application, using their network and infrastructure. Internally we never had issues starting our Balzor WASM application but about 50% of the customer that are testing the application can not start our Blazor WASM application due to their firewall blocking the application. Especially if the customer works in finances or insurance. In the financial sector it is not an option to advice the customer to change their firewall settings. We are suffering a massive loss of trust due to this issue. This issue is an absolute killer for Blazor WASM for our industry, and we are losing a lot of development effort if this issue will not be fixed…

Of course we tried workarounds: Like renaming the files. But this did not resolve the issue.

Currently we are trying the “Encoding files with service worker idea“ workaround but without using the service worker. The following sample code demonstrates how we try to solve it:

1. During our build process we generate for every dll additionally a base64 text files. sample_code.zip (DllEncoder.cs).

2. We disabled the auto start of the blazor app in our index.html <script src"_framework/blazor.webassembly.js" autostart="false"></script>

3. We use the “loadBootResource” extension to fetch the dlls and in case of 403 error we fallback to load the base64 text files. sample_code.zip (sample.js)

Probably this can help other developers with the same issue. But at the end we hope that Microsoft will fix the issue. Since tricking out firewall to get Blazor WASM running is not a good nor acceptable plan for us… This will not strengthen the trust in our software.

Just note that if packaging specifically for these firewalls is an extra step, an opt-in, then most Blazor wasm deployments will be inaccessible from these locations (i.e. large corporations with content inspection in proxy). As a developer you need to be aware of the problem and fix it. This means every developer has to learn this (often the hard way) and figure out how to solve it.

In terms of adoption, having a new tech that sometimes doesn’t work for some visitors for mysterious reasons is probably not good.

Just note that if packaging specifically for these firewalls is an extra step, an opt-in, then most Blazor wasm deployments will be inaccessible from these locations (i.e. large corporations with content inspection in proxy). As a developer you need to be aware of the problem and fix it. This means every developer has to learn this (often the hard way) and figure out how to solve it.

In terms of adoption, having a new tech that sometimes doesn’t work for some visitors for mysterious reasons is probably not good.

I completely agree with this. An out-of-the-box solution should work for this without having to do anything. Then, if something needs to be customised for additional requirements, then allow the mechanisms to make the changes or by project configuration choose the method to build those packages. Something like: Project options / Web/ Build/ Packaging : Default (Basic and works), Method2, Method3, None, Custom.

But by default make it work when compiling in Release mode.

Hi folks,

We have an update on this topic here

We added a feature on RC1 that allows people to create their own “packaging format” for blazor applications and have created an experimental package that packages the dlls in a different way as described in the blog post above. You should be able to use our extension package (or create your own package to reuse and share) that customizes how a Blazor app loads and where you can apply any transformation to the app dlls as part of the build process and undo the transformation afterwards.

Just want to add that I’m also running into this issue: our app was blocked by an internal VPN connection that people had to connect to with WFH restrictions in an enterprise setting. This impacts Blazors potential in enterprise environments and this is a real risk for adoption.

I would like to add some information about my experience with ESET Internet Security installed on my own laptop. This laptop has Core i7-6500U processor which is optimized for battery life and not performance. When ESET doesn’t monitor HTTPS traffic I have to wait about 1.5s to download and run default Blazor WASM ASP.NET Hosted application. When HTTPS traffic monitoring is enabled I have to wait three! times as long.

I have confirmed that browser downloads compressed files (*.br) but before they are delivered to the browser they are decompressed and scanned by ESET. This slows down the loading considerably. After scanning file is returned to the browser in uncompressed form and Content-Encoding header is removed. There is no double decompression. The slowdown is only due to an antivirus scanning.

It seems that the only solution is renaming and encoding but before you implement it you should contact with firewall/antivirus vendors and ask what they are going to do. It is possible that they implement an algorithm to decode all of these files, and we’ll be back to where we started.

@guardrex can you use the blog post as a base to document how to do this?

Ok, I tested modifying the header back on client side. It works and is fairly simple to implement. (Except that the published js file is minimized.)

I added the line data[0] = 77; after this line https://github.com/dotnet/aspnetcore/blob/c1d16e3ccd2df6a3ff06b7e0233ad96fe6113d5b/src/Components/Web.JS/src/Platform/Mono/MonoPlatform.ts#L460

This restores header from BZ to MZ with near zero overhead. (Note that this is a dirty proof of concept hack that assumes all files that goes through this function are supposed to start with M.)

Doing this the WebAssembly loaded successfully.

Attaching the complete code for modifying binaries for test, including updating compressed files and updating sha256. It is just a quick hack ran from LINQPad.

void Main()
{
	var dir = @"C:\path\to\project\bin\Release\net6.0\browser-wasm\publish\wwwroot\_framework";
	var dllFiles = Directory.GetFiles(dir, "*.dll");
	// Modify header on .dll-files
	foreach (var file in dllFiles)
		FlipBz(file);

	// Create new compressed copies
	foreach (var file in dllFiles)
	{
		CompressBr(file);
		CompressGz(file);
	}

	// Update sha256 checksum in blazor.boot.json
	var shas = new Dictionary<string, string>();
	foreach (var file in dllFiles)
	{
		using SHA256 mySHA256 = SHA256.Create();
		using var fs = File.Open(file, FileMode.Open, FileAccess.ReadWrite);
		var sha256 = mySHA256.ComputeHash(fs);
		var base64Sha256 = Convert.ToBase64String(sha256);
		shas.Add(Path.GetFileName(file), base64Sha256);
	}
	var jsonFile = Path.Combine(dir, "blazor.boot.json");
	var json = File.ReadAllText(jsonFile);
	foreach (var kvp in shas)
	{
		// This is what happens when you used to be a Perl programmer
		var r = $"(\"{Regex.Escape(kvp.Key)}\":)[^,]+(,)?$";
		json = Regex.Replace(json, r, $"$1 \"sha256-{kvp.Value}\"$2", RegexOptions.Multiline);
	}
	File.WriteAllText(jsonFile, json);
	CompressBr(jsonFile);
	CompressGz(jsonFile);
	//json.Dump();
}
void CompressBr(string file)
{
	using var input = File.OpenRead(file);
	using var output = File.Create(file + ".br");
	using var compressor = new BrotliStream(output, CompressionMode.Compress);
	input.CopyTo(compressor);
}
void CompressGz(string file)
{
	using var input = File.OpenRead(file);
	using var output = File.Create(file + ".gz");
	using var compressor = new GZipStream(output, CompressionMode.Compress);
	input.CopyTo(compressor);
}
void FlipBz(string fn)
{
	using var fs = File.Open(fn, FileMode.Open, FileAccess.ReadWrite);
	using var bw = new BinaryWriter(fs);
	var bz = Encoding.ASCII.GetBytes("BZ");
	bw.Write(bz);
}

@legistek Obfuscation / encryption is not an option in my opinion. “Good viruses” have been using these techniques for years, and antivirus vendors have caught them anyway. This solution will work a few hours, maybe a few days at most.

Hi @eguardiola

we thought about compressing the data too instead of using base64 strings. Currently we did not implement it because we hope there will be a fix in dotnet 6.0 somehow and we can remove the current workaround.

Blazor itself writes the downloaded dlls into the cache. Per client the download happens only once. This mechanism still works when you are using a custom loadBootResource function.

We invested some time to check out some libraries which could help. One simple solution for use would be to use lz-string compression:

Client Side: https://pieroxy.net/blog/pages/lz-string/index.html

.Net on Build Server: https://www.nuget.org/packages/LZStringCSharp/