Consider changing URLs of .NET assemblies not to end with .dll

[Rast1234]

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?

[SteveSandersonMS]

That's interesting - thanks for letting us know. We'll look at changing the URLs to YourAssembly_dll or something like that, though whether we do it by default may depend on whether we get more reports about this, and whether we can establish it's due to the name or deeper inspection of the payload contents.

[galvesribeiro]

@SteveSandersonMS just to drop my 2c here. It is not just corporate firewalls that suffer of the .dll-fobia. Some local anti-virus have this same problem too.

[joeizy]

@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 :)

[galvesribeiro]

@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...

[wilka]

How about YourAssembly.blazor? It might be a nice way to promote the project (very very slightly) if any web devs folks look in the dev tools to see how the site was built? Or maybe it's just just me that sometimes spots that a site was a built with Vue.js or whatever and thinks "oh, nice" :)

[Manuel-S]

How about simply .bin?

[galvesribeiro]

I like .bin or .blazor as well.

[joeizy]

+1 “.bin”

[grahamehorner]

.lib or .bin or .ilasm ?

[SteveSandersonMS]

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 .dll, either by default or in a common configuration? Can you point me to something I can install and try out? Or if not, do you have the name of it at least, and perhaps links to any of its configuration docs?

[galvesribeiro]

@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.

[miroslavp]

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 https://msdn.microsoft.com/en-us/library/cc190632(v=vs.95).aspx

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.

[galvesribeiro]

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...

[miroslavp]

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.

[vibeeshan025]

Keep ".net" as extension

[SteveSandersonMS]

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.

I think it is not a particular product

Nonetheless, examples of particular products, and under what configurations this happens, would help.

[galvesribeiro]

@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:

1. Sign the assemblies as usual and;
2. Make sure the naming is not in the default blacklist

[grahamehorner]

@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.

[SteveSandersonMS]

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?

[danroth27]

From https://www.paloaltonetworks.com/documentation/80/pan-os/pan-os/threat-prevention/set-up-file-blocking:

File Blocking Profiles allow you to identify specific file types that you want to want to block or monitor. For most traffic (including traffic on your internal network) you will want to block files that are known to carry threats or that have no real use case for upload/download. Currently, these include batch files, DLLs, Java class files, help files, Windows shortcuts (.lnk), and BitTorrent files.

[grahamehorner]

@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.

[grahamehorner]

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 ?

[galvesribeiro]

Currently, these include batch files, DLLs, Java class files, help files, Windows shortcuts (.lnk), and BitTorrent files.

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...

[galvesribeiro]

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.

[itsamelambda]

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... http://webassembly.github.io/spec/core/binary/conventions.html

The recommended extension for files containing WebAssembly modules in binary format is “.wasm” and the recommended Media Type is “application/wasm”.

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.

[rstropek]

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.

[FabriDamazio]

Antivirus AVG version 18.1.3044 blocked the DLL files too when i tried to visit https://blazor-realworld.azurewebsites.net/

[itsamelambda]

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.

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

The .NET binary format is based on the Windows PE file format. In fact, .NET class libraries are conformant Windows PEs, and appear on first glance to be Windows dynamic link libraries (DLLs) or application executables (EXEs). This is a very useful characteristic on Windows, where they can masquerade as native executable binaries and get some of the same treatment (for example, OS load, PE tools).

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.

[JonnyGibson]

If the Blazor model does not play 100% well with existing firewalls it is almost a show stopper.

@SteveSandersonMS sorry if you've answered this before, but do you envisage this being solvable?

[SteveSandersonMS]

Of course! We will change either the URLs or content format as needed.

[JonnyGibson]

it would be great if this could get prioritised for the next milestone. Would realy allay people's fears that it's a show-stopper due to potential corporate security blocks

[danroth27]

@JonnyGibson As Steve mentioned earlier, we do plan to address this, but in the spirit of Blazor being an experiment project we're prioritizing work right now that is less well understood. We're pretty sure we know how to address this one.

[torhovland]

Here's another example:

[jonparker]

Maybe a solution would be to let the developer define the extension for an app until firewalls and AV add support in the whitelist for whatever extension is decided on.

[jonparker]

Regarding my previous comment on letting the developer define the extension this would also allow developers to create apps with different extensions to test out the firewall and Antivirus behaviour.

[JonnyGibson]

@jonparker @torhovland it feels to me that as opposed to defining extensions which may or may not get blocked, we need to find a way that ensures its never blocked. No one is going to use a framework that is going to cause a web site to be blocked under some (quite likely) scenarios.

The idea to remove the extension seems reasonable and should be tried asap. I haven't seen any other issues raised which are as close as this is to being a showstopper.

[danroth27]

The idea to remove the extension seems reasonable and should be tried asap.

In order for us to test any fix we need to be able to reproduce or at least investigate as many problematic environments as possible. To help us with that please continue to provide details on your environments where you run into issues with Blazor apps getting blocked. Thank you everyone who has already reported on this!

I haven't seen any other issues raised which are as close as this is to being a showstopper.

In the long run we're not too concerned about this issue. We're pretty confident that we will be able to handle this issue with some form of app packaging or app transformation. But we're holding off on designing a solution until we have more data on what the specific problems are.

[JonnyGibson]

WebSense is the tool my corporate network uses to control web access. I'm pretty sure that the issue blocking Blazor is just their explicit executable file download blocking. https://www.websense.com/content/support/library/web/hosted/admin_guide/exten_block.aspx

[msdickinson]

Looks like AVG is blocking my blazor project. https://files.gitter.im/aspnet/Blazor/Oc8w/image.png

[krzychuwr1]

I can confirm I also had experience with AVG blocking my website. My friend couldn't access the website without disabling AVG. as far as I know he used the default antivirus settings.

[WinInsider]

DLL extension is non issue... With AOT compilation in the works, DLLs will not be distributed, as I understand DLLs are used for quicker dev loop. Don't spend time on this, get AOT working, that's the goal.

[jorisvergeer]

A well... #897 was a duplicate.

This was my error

[RemiBou]

maybe we can set the extension as a parameter in UpdateIndex where we would get it from the command line (default "dll") : https://github.com/aspnet/Blazor/blob/dev/src/Microsoft.AspNetCore.Blazor.Build/Core/IndexHtmlWriter.cs

If I send a PR on this, would it be considered ?

[itsamelambda]

Please fix this issue, it is the only item blocking me from testing this in the enterprise.

[RemiBou]

Quick fix suggestion if you are using IIS with the rewrite url module :

• you can change in the output all ".*.dll files by .wasmnet or anything. his will edit the content of the script tag (https://docs.microsoft.com/en-us/iis/extensions/url-rewrite-module/creating-outbound-rules-for-url-rewrite-module)
• rewrite this extension to dll so the good files will be send to the browser (or rename the dll files after deploying)

you might be able to do this with .net core https://docs.microsoft.com/fr-fr/aspnet/core/fundamentals/url-rewriting?view=aspnetcore-2.1&tabs=aspnetcore2x

[jiggyswift]

Just another idea: I note that most of these firewall and security products don't block .zip files. In fact, many times when trying to download a .dll file where I am blocked on some corporate network, I notice a .zip version of the same file will almost always pass the blocking.

So we could simply package MyLib.dll as MyLib.zip (containing a single MyLib.dll file inside the zip). The problem is that the browser will natively be faster decompressing the files contents compared to if it was WASM/MONO using some .NET assembly to unzip the compressed archive's content. There would be at least a 2x-3x slowdown for the unzip.

But there is a solution: We could package the MyLib.dll file as MyLib.zip with ZERO compression used, then leave it up to the web server to compress the file (using whatever compression formats the client browser supported when requesting the file). When the browser downloads that file, it will natively decompress the received content, before it hits Mono/WebAssembly. So the Mono runtime would then just need to unpack the .zip file (which at this point is the original uncompressed zip archive).

I hope nobody is confused by the above. I am just suggesting that we use .zip as an uncompressed container format; then let the web browser and web server handle compression and decompression the way they do normally for any requested file. To give a concrete example:

1. 2 MB mscorlib.dll gets .zipped into 2 MB mscorlib.zip (note we set compression to NONE).
2. Web browser requests mscorlib.zip (sending usual Accept-Encoding headers with compression methods supported).
3. Web server compresses content of mscorlib.zip down to 700 MB and sends that to server, so the package size would be the same as it is today)
4. Web browser (Chrome or Edge, etc) decompresses content natively, and the Mono runtime would receive the original 2 MB mscorlib.zip file, which WASM Mono can unpack to the original .dll really fast because there isn't any internal compression used on that original zip archive.

So that is just another suggestion to include in the bucket. My thoughts on other ideas suggested:

• I would hope it would be enough just to remove the extension, as in MyLib.dll becomes MyLib or the earlier MyLib_dll suggestion.
• I also agree it should be possible to "package" the assembly as data inside a .wasm file (but still internally in IL format) in the same way .NET assemblies use the PE format and were given .dll as an extension. So we could have a MyLib.wasm that internally stored the IL as data. The only disadvantage I see here is when we have real AOT compilation it might be hard to visually tell if a .wasm file contained IL or Natively (WASM) compiled code.

[MovGP0]

.dll would be the proper extension and should be kept as default. Hiding the intention of the file by changing the extension to .zip isn't an optimal solution, since it produces confusion. It would probably be better to use no extension at all and name the file like somedllname_v1_0_0_4321_ab5e8d5b97d141aca3c54776e82d2355 (that is project name, file version and an SHA-256 hash)

A bigger problem is, that current AV scanners (heuristically) detect routines which fetch additional code. There is no real solution to that problem until AV vendors make adaptions to support .wasm. So better contact the AV vendors and report as a bug, such that they can fix it.

[Andrzej-W]

I 100% agree with @MovGP0. AV vendors have to update their software. They use different algorithms to detect malicious code and those algorithms have to be smart enough to block viruses and allow legitimate software. I believe that every modern AV scanner checks content of every archive, zip, 7z, rar, etc. Changing file name extension or pseudo-packing is not a long term solution.

[jiggyswift]

It just seems silly that this is an issue because the blocking is due to legacy reasons. There are two scenarios with Blazor for DLLs:

1. IL code running interpreted in a browser: In this case the IL code in the DLL is just raw DATA, and no more threat than a JPG or XML file the browser is processing. This is because the downloaded IL is being completely interpreted. The security product has no more business with this than it does with whatever GIF, XML or TXT file a website is processing.

or (in the future)

1. IL code compiled AOT to .wasm. In this case the IL code would generate .WASM and the only issue should be how these security products handle .wasm files.

Another point about “packing” is that this is exactly what many javascript frameworks already do to reduce requests to the server: have some server side script dynamically combining multiple separate script filed into a single file. I would personally love to see some intelligent server side handler that could dynamically combine 20 small (5k) DLLs to reduce initial server requests and let me as a developer optionally have some control over that during page load.

But I think the Blazor team has our feedback now and will do whatever is sensible and/or provide options.

I will point out that a view that we must wait until everyone updates their security products doesn’t work because it isn’t just products it is existing large companies that won’t realistically make configuration changes to their network infrastructure. This will really hurt Blazor use because it is not just about AV scanners it is about trying to tell staff within an IT department of large company like News Corporation or Bhp Billiton to make network configuration changes. Culture is changing, but there are still many staff in those departments that simply wouldn’t care (or would actively smile) if this caused Blazor issues ☹.

• I believe that every modern AV scanner checks content of every archive, zip, 7z, rar, etc. My personal experience over the last decade is that when in .zip form everything is usually fine. Things are usually blocked if the files are .exe or .dll. Within a zip archive most products would only block the zip file if they detect an actual known signature of malware within the zip archive (not just because there is a .dll inside). But I acknowledge every product is different so there are not any guarantees here. From: Andrzej-W notifications@github.com Sent: Wednesday, 6 June 2018 5:38 AM To: aspnet/Blazor Blazor@noreply.github.com Cc: jiggyswift mail@davtaylor.com; Comment comment@noreply.github.com Subject: Re: [aspnet/Blazor] Consider changing URLs of .NET assemblies not to end with .dll (#172)

I 100% agree with @MovGP0https://github.com/MovGP0. AV vendors have to update their software. They use different algorithms to detect malicious code and those algorithms have to be smart enough to block viruses and allow legitimate software. I believe that every modern AV scanner checks content of every archive, zip, 7z, rar, etc. Changing file name extension or pseudo-packing is not a long term solution.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/aspnet/Blazor/issues/172#issuecomment-394834055, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AmF6aIkiXWAVe282A0YSh_a7bgmGPGN7ks5t5t4OgaJpZM4SUpej.

[mcintyre321]

I had two people from the Corporate Security Team come to my desk after I browsed the the mono wasm example site, which downloads a hello.exe. I think it was picked up by "Symantec Endpoint Protection".