New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider changing URLs of .NET assemblies not to end with .dll #5477
Comments
That's interesting - thanks for letting us know. We'll look at changing the URLs to |
@SteveSandersonMS just to drop my 2c here. It is not just corporate firewalls that suffer of the |
@galvesribeiro is right not to mention that if I wasn’t familiar with what’s going on and I saw a website trying to download a DLL I’d be out of there! Consider the perception when addressing this :) |
@joeizy yeah, I totally agree with you that for the majority of cases block dlls is the right thing todo. That is Why we are talking about renaming it as we are sure what we are doing... |
How about |
How about simply .bin? |
I like .bin or .blazor as well. |
+1 “.bin” |
.lib or .bin or .ilasm ? |
So we can make an informed decision about this, it would really help if we had approximate repro steps (or at least some hint in that direction). We need to understand specifically whether it's a naming issue or a content issue, for example. What specific firewall product is known to block |
@SteveSandersonMS I think it is not a particular product. Multiple products, specially the ones heavily used by enterprises have tide config settings on file types specially the common ones like .exe, .dll, .so, etc. The name itself is the first blocker but, one way to reduce this issue, is the same way we've dealing with ClickOnce since .Net 2.0. Signing assemblies. The problem is that (1) it is not cheap, (2) the process to earn those certificates even if you can afford them is VERY complex and even not available in some countries and even if you get it, (3) the certificate for the company/developer usually takes a while to be trusted by the antivirus software database. For MSFT released assemblies, it is not a big news as we know that every shipped assembly, even OSSed ones, are code signed by corpnet policy. But think about other developers, startups, and OSS projects. They will all suffer with that. |
I remember that in the good old days when Silverlight was a thing, if we wanted to download assemblies on demand, we put them in a xap file (which in practice is a zip file) and then extracted them with Not sure if there was a reason for that (other than combining multiple dlls in a single file). I guess the Silverlight team should be familiar with the firewall issues if there are any. |
The problem with bundling together is that if you need to update 1 of those dlls the whole package must be updated... Not cache or bandwidth friendly the Silverlight model... |
I'm not suggesting to use bundling for Blazor. I'm just saying that apart from the bundling feature, maybe the Silverlight team was using xap files to avoid firewall issues. That's just a guess, of course. |
Keep ".net" as extension |
We're well into the realms of bikeshedding on this now. Hence I'm specifically asking for concrete examples of actual firewall products that have trouble with this.
Nonetheless, examples of particular products, and under what configurations this happens, would help. |
@SteveSandersonMS I understood that part. The point is that fix the issue for 1 particular antivirus/firewall will not cover all the others as we all know that each one has its own heuristic, database, settings for that. The only case that could cover both the naming and signature rules for everything, is:
|
@SteveSandersonMS I've seen a few issues when using NOD32 from ESET and have seen the active scanner block downloading some binary files silently, these seem on the face of it to be Dynamic Link Libraries that do not have a digital signature. |
Thanks for the info @grahamehorner. Do you know roughly what the repro steps would be? If I just installed NOD32 onto a (throwaway) Windows machine, is that enough to make it unable to open https://blazor-demo.github.io/? Or is any additional config needed? |
|
@SteveSandersonMS I'm awaiting a meeting with our IT Administration Team that remotely manages NOD32 and it's configuration to find out what (if anything) they have changed/customised, as I've also received an automated email from our NOD32 system stating that I have may violated corporate security policy by downloading/installing untrusted software. I'll post back as/when I find out or have additional info. |
I'm wondering if the .dlls could/would be blocked if they got packaged up into a .nupkg and unpacked/loaded by blazor after download ? |
That is what I'm saying... Regardless of the product, that is the default list of file types that would be blocked by any IT administrator in regular (usually non-IT-based) company... |
BTW, if there is someone from the WPF team that worked with .xap, they can clearly tell anyone what they faced when they released "WPF in a Browser" back in the day and faced exactly same problem. It took a while until all the anti-virus software start to trust on that extension. |
I had the same issue. Tested the sample inside a corporate network. A DLL file was reported as being blocked. This basically makes it impossible to demo this to a colleague. Getting DLL files to be unblocked is probably a non-starter. Looking at the official conventions page...
So it would seem that the first thing to do is to rename the files to .wasm, and if they are still blocked, then the firewall needs to be unblocked. |
I don't think that renaming the files to .wasm is a good idea. The DLLs are no Wasm modules, they are .NET assemblies which are (currently) interpreted by the Mono Wasm runtime (read more). Only the Mono runtime is a Wasm module. However, I also vote for renaming the DLLs to something else because of firewalls especially in enterprise scenarios. |
Antivirus AVG version 18.1.3044 blocked the DLL files too when i tried to visit https://blazor-realworld.azurewebsites.net/ |
The problem is what that "something else" extension would be because none of the existing extensions apply (.NET MSIL payloads interpreted directly in the browser sandbox is a brand new concept in security) whereas wasm is already allowed by the corporate firewall. The handling of .xap may not be a good reference from a security standpoint because it bypasses the browser security sandbox unlike wasm. Yes, the DLL files contains MSIL so it is technically true, they are not strictly binary wasm. But they are named DLL because they are named after native Win32 DLLs even though they just share a fragment of the PE format and are mostly different internally anyway. Along the same lines, wasm is the "native" library format for Webassembly, and for the same reason that it made sense to name managed libraries DLL:s (even though they are nothing like native DLL:s internally), it can make sense to name them wasm. From a security perspective, DLL implies "local execution" whereas wasm implies "browser execution". To comply with the wasm format, perhaps the .NET assembly could be embedded as data to make it a valid wasm with the magic initial string and all. The idea here is that there is an analogue: wasm is to MSIL what PE is to MSIL: a wrapper container format. Precendent: https://docs.microsoft.com/en-us/dotnet/standard/assembly-format
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. |
@SteveSandersonMS sorry if you've answered this before, but do you envisage this being solvable? |
@danroth27 I dont think you published preview2 yet... :) |
You can try this with the nightly builds following the instructions here if you choose to do. I would recommend you clear your nuget package caches before and after if you choose to do that. Take into account that clearing the caches will impact the entire machine (all apps in that machine) |
I'll wait for the p2 build to be released and then try it out. Thanks! |
@mrpmorris 3.2 Preview 2 is now available! Do the steps suggested in #19558 (comment) for renaming the files work for you? |
Hi folks! In the recent Blazor WebAssembly 3.2 Preview 2 release we made some changes to make it easier to rename the .dll files in your app as a way to address proxies/firewalls/antivirus software interfering with Blazor WebAssembly apps. We'd like folks who are hitting this issue to try out the steps below on the published output of your Blazor WebAssembly apps (standalone or ASP.NET Core hosted) and see if it helps: Windows
Linux / macOS
Please give these steps a try and let us know how it goes. If you still run into problems please let us know! We have some other ideas of things to try if necessary. Thanks! |
That worked for me. Although I had to adjust my publish step on Azure DevOps and deactivate that it generates a zip at the end. In my case:
|
@NPadrutt It worked in what sense? In the sense that you conclusively observed your site was not working before (due to some kind of antivirus or firewall), and the change of URLs fixed this? If that is the case, would you please be able to post details of what antivirus/firewall/etc was causing problems for you before at #19552? Thanks! |
@SteveSandersonMS well, I had previously the work around via the rewriter in place. After the upgrade to the 3.2 preview 2 that one didn't work anymore and the application was blocked again. With the above it is working again. Unfortunately I can't tell you what firewall we have in our network and I don't think that the AntiVirus (McAffee) has an impact here, since working locally worked without problems. |
Someone at my office has tested positive for COVID-19, so it looks like my office will be closed for a couple of weeks - which means I won't be accessing files through their firewall. Sorry. |
@mrpmorris No problem. Stay safe! |
I ran the script (I develop on Windows, but I deploy from a Linux environment to another Linux environment, so I used the Linux script provided) and it deployed with the new names, and when loading the page it seems to be loading the files with the new extensions fine, and the app works. In our case, Avast no longer flags the app and no longer blocks downloads. Due to the pandemic situation, it'll be a bit before we check the corporate firewall situation. This is a simple enough step to add to the build and appears to have no downside, so we will start using it. Thanks! |
@danroth27 is this going to be the default at some point so we don't need to do this step? Is there really any reason to not just move to .bin or no filetype as the default instead of requiring everyone to do this if there is a general issue with .dll file type? Is there any chance that a virus checker will check the file even if it isn't ".dll" to see if it is a dll file? |
@danroth27 @SteveSandersonMS
I tried the steps @danroth27 mentioned both on Windows and on a Linux Docker container with the same results. Using 3.2 Preview 4. |
@radderz This issue doesn't appear to affect all environments - it's specific to certain environments and is often policy based. If we switch to a different file extension there is no guarantee that this will work for everyone. So, instead of changing the default for everyone, we are going ahead with the plan where customers that hit this issue can control the file extensions themselves using the technique provided above. It is certainly possible that antivirus software/proxies/firewalls may do a deeper inspection of the files than just look at the file extension. So far we haven't heard of anyone getting blocked by this yet. If this becomes a problem, we will at other mitigations. |
@mihaimyh Looks like you might have a misconfigured content security policy? |
@danroth27 Can you, please, be more explicit? What security policy are you talking about? I got those errors even on dev environment where I believe there is no security policy implemented. |
@mihaimyh Sorry, I think I mixed up content security policy with subresource integrity. It looks like the browser is trying to enforce that the hashes of downloaded assets match hashes specified in markup via the |
@danroth27 Ok, and I believe I can bypass integrity checking by adding
to my .csproj files but I still got 404 event with integrity checking disabled. |
@mihaimyh If you can reproduce this reliably, I would suggest opening up a new issue for this problem, as it doesn't appear to be related to the file extensions issue. That will make it easier to engage the right folks. |
Make sure that you add something like this in your "dll rename" script
Most of the time the precompressed blazor.boot.json will be downloaded instead of the "fixed" blazor.boot.json making requests to the ".dll" files instead of the ".bin" files causing the integrity issue. So you have to either remove the compressed json files or recompress the blazor.boot.json but I don't think it is worth it to go through that hassle. Hopefully one day this could all be handled by the framework with a flag in the csproj, e.g.
|
Hi folks. At this point we've documented the strategy we recommend for changing the file extension for the published .NET assemblies using scripts. I think @stavroskasidis's suggestion is still a good one to provide a simple built-in way to do this, so I've opened #21489 to track the suggestion. At this point I think we're ready to close this issue. Thanks everyone for the detailed feedback provided! |
From what I can see the rename from .dll to .bin must be done also in |
I wanted to see the demo at https://blazor-demo.github.io/ and my corporate firewall blocked
MicroApp.dll
, while other dlls downloaded successfully. Since a lot of software is paranoid about downloading/transferring windows binaries, maybe it's worth obfuscating them a bit? Or, at least, renaming?The text was updated successfully, but these errors were encountered: