Description
Describe the bug
Users are unable to access our Blazor application because their corporate firewalls block downloading the .NET assembly files. We followed the guidelines MS published and mentioned in #5477 (comment) to rename the '.dll' files to '.bin', but the assembly files are still being blocked.
One of the firewall systems we've identified is TrustWave WebMarshal. Of course such products are configurable, but by default this product appears to block Blazor apps. It appears it may be the content of the .Net assemblies that are being blocked. The firewall security team have made it clear than allowing DLL's is a hard 'no'.
Others report in #21996 and #19552 (comment) that Sophos Antivirus also blocks Blazor application due to the .Net assembly files and that renaming the files does not work there either. Others suggest implementing XOR encoding for transit, but I haven't found a good implementation.
Others report in #23084 that McAfee Web Gateway blocks Blazor .Net assemblies, even when renamed, based on content because they are detected as "application/dotnet-assembly".
Others mention in #21996 (comment) that their (unnamed) firewalls block on content not file extension so renaming does not help and that a fairly complex base64 encoding process to preload the assemblies into the cache and then refresh is a workaround.
Others report in #19552 (comment) that Palo Alto firewall and in #19552 (comment) and #16247 and #5477 (comment) and #5477 (comment) that Avast Antivirus / AVG Antivirus blocks Blazor, but possibly the renaming of DLLs works there? I could find anyone confirm if that actually worked.
Others report in #16247 (comment) that Symantec Web Firewalls blocks Blazor apps, unclear if only by filename or content.
Others report in https://forums.asp.net/t/2161027.aspx that Norton Antivirus blocks Blazor apps by detection of the DLL content.
This appears to be a massive road-block to Blazor adoption. Past security sins mean that no one trusts anything that smell like a dll/exe. I think Blazor needs a native / built-in solution to either encodes the payloads so they they don't look like traditional security risks. Really I think the Blazor application should be compiled to WASM when published, so it is only wasm code that is being downloaded. There are discussion of upcoming 'AOT' compiling feature coming since 2018, which sounds like a proper solution.
@Vectorix states it well:
"If the Blazor model does not play 100% well with existing firewalls it is almost a show stopper. It should flow through all firewalls effortlessly just like Javascript. If I was a firewall administrator, I am not sure if I would want to add a new white list entry for each new languages that has its own IL format."
Questions:
Has any developed a workaround that will enable Blazor use in corporate settings?
Does Microsoft have published advice for firewall vendors how to allow Blazor while blocking traditional DLL attacks?
Does the .Net 6.0 preview 1 fix this in any way?
Should deploying Blazor in the real world be this hard? 😀
@mkArtakMSFT you have often commented on this issue, and often say you hear of this issue rarely. But are you sure there lots of people using Blazor with corporate users and not experiencing this problem? If so many products like WebMarshall, Sophos, McAfee, Norton, maybe Symmantec and other all block Blazor/.Net by default on content not filename, that seems like a huge barrier to adoption? And if all of those plus Palo Alto, Avast/AVG, and presumably others block on filename, should '.dll' even be the filename or encoding used for IL files?
To Reproduce
Publish with:
dotnet publish --output foo --configuration Release
Then rename DLLs with:
for f in wwwroot/_framework/*.dll; do mv "$f" "${f/.dll}".bin; done
sed -i 's/\.dll"/.bin"/g' wwwroot/_framework/blazor.boot.json
sed -i 's/\.dll\$/.bin\$/g' wwwroot/service-worker.published.js
The resulting application works fine when the firewall is not blocking it, but try to access it behind many web proxy firewalls will fail.
Exceptions (if any)
Each .Net assembly is blocked by the firewall and fails with:
Class name: TypeError
Message: Failed to fetch
Tags: UnhandledPromiseRejection
Further technical details
-
ASP.NET Core version 5.0.201
-
Include the output of
dotnet --info
.NET SDK (reflecting any global.json):
Version: 5.0.201
Commit: a09bd5c86c
Runtime Environment:
OS Name: ubuntu
OS Version: 18.04
OS Platform: Linux
RID: ubuntu.18.04-x64
Base Path: /usr/share/dotnet/sdk/5.0.201/
Host (useful for support):
Version: 5.0.4
Commit: f27d337295
.NET SDKs installed:
3.1.404 [/usr/share/dotnet/sdk]
5.0.201 [/usr/share/dotnet/sdk]
.NET runtimes installed:
Microsoft.AspNetCore.App 3.1.10 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.4 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 3.1.10 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.4 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
To install additional .NET runtimes or SDKs:
https://aka.ms/dotnet-download
- The IDE (VS / VS Code/ VS4Mac) you're running on, and its version
Linux CLI and VS 2019
References
#5477 (comment)
#21996
#21996 (comment)
#23084
#19552 (comment)
#19552 (comment)
#16247
#5477 (comment)
https://forums.asp.net/t/2161027.aspx
Microsoft guidelines for renaming files
Encoding files with service worker idea