Inheritance security rules violated by type: 'System.Net.Http.WebRequestHandler'. Derived types must either match the security accessibility of the base type or be less accessible.

[clairernovotny]

Using the latest System.Net.Http 4.1.1 as per #17770 (comment), results in an exception when starting a web app that's .NET 4.6.1:

Inheritance security rules violated by type: 'System.Net.Http.WebRequestHandler'. Derived types must either match the security accessibility of the base type or be less accessible.

I've emailed a repro to @davidsh

---

Execution plan & status

[UPDATED by karelz]

High-level plan:
A. Revert HttpClientHandler implementation in net46 build of CoreFX back to using original .NET Framework HTTP stack instead of WinHTTP (WinHttpHandler) based stack.
B. Revise implementation of the 8 new APIs on HttpClientHandler we introduced in 4.1.0.0 OOB package so that it works accordingly for the net46 build.

Execution plan:

1. Validate feasibility of [A]

   • a. Port HttpClientHandler from NetFX (remove WinHttpHandler build dependency for net46 build).
   • b. Add APTCA (on assembly only, no security attributes should be necessary for types or methods - same as in Desktop source code).
     • Run the SecAnnotate tool to verify the claim above - Result: Passed
   • c. Manually test the 2 scenarios (simplified and @onovotny’s) - Result: Verified

2. Validate feasibility of [B]

   • a. Investigate the 2 remaining APIs (DefaultProxyCredentials, MaxConnectionsPerServer) which we do not know if we can implement. - Result: They are in the bucket 4.a below.

3. Full testing of [A] implementation (cost: 1d)

   • a. Make changes in master
   • b. Test all ~7 end-to-end scenarios reported by community (ask for help from community, provide steps to consume master packages on myget)
     • Self hosting ASP.NET Core from Windows Service - validated by @annemartijn0 (here)
     • Azure Storage API - validated by @karelkrivanek (here)
     • Raven.Database package + usage of new HttpClientHandler - validated by @jahmai (here)
     • Direct dependency on System.Net.Http - validated by @pollax (here)
     • 4.6 console app depending on System.Net.Http - validated by @MikeGoldsmith (here)
     • 4.6 Azure webjob (console app) with ServiceBus - validated by @chadwackerman (here)
     • 4.6 Azure Batch app - validated by @chadwackerman (here)
     • Not-yet-described scenario by @dluxfordhpf

4. Full implementation and testing of [B]

   • a. Decide on design of 4 APIs (CheckCertificateRevocationList, SslProtocols, DefaultProxyCredentials, MaxConnectionsPerServer) which we can’t implement “correctly” - we have 3 choices - either throw PlatformNotSupportedException, or do nothing, or set the properties domain-wide instead of per-HttpClient-instance
     • i. Implement the decision (cost: 2d)
     • ii. List all libraries on NuGet (e.g. WCF?) which use the APIs we will be technically breaking, contact them
       • 4 NuGet libraries potentially affected - owners contacted - see details and tracking progress
   • b. Implement 5 APIs which we know how to implement (cost: 3d)
   • c. Final testing on master branch package - covered by [3.b]

5. Ship final packages

   • a. Port changes into release/1.1.0 branch
   • b. Produce new package - 4.3.1
   • c. Test most of ~7 end-to-end scenarios reported by community (ask for help from community, provide steps to consume 4.3.1 stable package from myget feed - see here)
     • Self hosting ASP.NET Core from Windows Service - @annemartijn0
     • Azure Storage API - @karelkrivanek
     • Raven.Database package + usage of new HttpClientHandler - @jahmai
     • Direct dependency on System.Net.Http - @pollax (here)
     • 4.6 console app depending on System.Net.Http - @MikeGoldsmith
     • 4.6 Azure webjob (console app) with ServiceBus
     • 4.6 Azure Batch app
     • Not-yet-described scenario by @dluxfordhpf
     • KeyVault - @Vhab (here)
     • SignalR - @tofutim (here)
     • OwlMQ - @JoeGordonMVP (here)
   • d. Publish package on nuget.org - https://www.nuget.org/packages/System.Net.Http/4.3.1

---

Impact of the change - Breaking changes

Here's list of technical breaking changes caused by the proposed solution. It includes workarounds for each.
Note that these new behaviors are specific when running on net46 / Desktop. When you run on .NET Core, the behavior is intact.

1. HttpClientHandler.CheckCertificateRevocationList (introduced in System.Net.Http 4.1)
   • New behavior: Throws PlatformNotSupportedException
   • Workaround: Use ServicePointManager.CheckCertificateRevocationList instead (impacts the whole AppDomain, not just single HttpClientHandler as it did in System.Net.Http 4.1-4.3)
2. HttpClientHandler.SslProtocols (introduced in System.Net.Http 4.1)
   • New behavior: Throws PlatformNotSupportedException
   • Workaround: Use ServicePointManager.SecurityProtocol instead (impacts the whole AppDomain, not just single HttpClientHandler as it did in System.Net.Http 4.1-4.3)
3. HttpClientHandler.ServerCertificateCustomValidationCallback (introduced in System.Net.Http 4.1)
   • New behavior: Works fine, except that the first parameter of type HttpRequestMessage is always null
   • Workaround: Use ServicePointManager.ServerCertificateValidationCallback
4. HTTP/2.0 support (introduced in System.Net.Http 4.1)
   • New behavior: System.Net.Http (for net46 = Desktop) no longer supports HTTP/2.0 protocol on Windows 10.
   • Workaround: Target System.Net.Http.WinHttpHandler NuGet package instead.
   • Details:
     • HTTP/2.0 support is part of the new CoreFx HTTP stack which on Windows is based on WinHTTP. The original HTTP stack in .NET Framework 4.6 did not support HTTP/2.0 protocol. If HTTP/2.0 protocol is needed, there is a separate NuGet package, System.Net.Http.WinHttpHandler which provides a new HttpClient handler. This handler is similar in features to HttpClientHandler (the normal default handler for HttpClient) but will support HTTP/2.0 protocol. When using HttpClient on .NET Core runtime, the WinHttpHandler is actually built-in to HttpClientHandler. But on .NET Framework, you need to explicitly use WinHttpHandler.
     • Regardless of whether you are running using .NET Framework runtime (with WinHttpHandler) or .NET Core runtime using HttpClientHandler (or WinHttpHandler), there are additional requirements in order to get HTTP/2.0 protocol working on Windows:
       • The client must be running on Windows 10 Anniversary Build (build 14393 or later).
       • The HttpRequestMessage.Version must be explicitly set to 2.0 (the default is normally 1.1). Sample code:

            var handler = new WinHttpHandler();
            var client = new HttpClient(handler);
            var request = new HttpRequestMessage(HttpMethod.Get, "http://www.example.com");
            request.Version = new Version(2, 0);

            HttpResponseMessage response = await client.SendAsync(request);

[ericstj]

I happened to look at this today from another report. /cc @ChadNedzlek

This looks like it might be due to missing security attributes on the out-of-band System.Net.Http.dll compared to the inbox System.Net.Http.dll. Inbox version has AllowPartiallyTrustedCallers. So does the inbox System.Net.Http.WebRequest.dll. This means everything is treated as SecurityTransparent unless annotated otherwise.

The OOB System.Net.Http.dll is missing AllowPartiallyTrustedCallers, which makes everything security-critical. Now when the inbox WebRequest.dll loads the OOB System.Net.Http.dll it violates the security rule, since WebReqeuestHandler is transparent, but HttpClientHandler which it derives from is critical.

My repro:

1. File > new desktop application
2. Project properties > signing > enable strongname signing
3. Add reference to System.Net.Http.WebRequest
4. Install System.Net.Http 4.1.0.
5. In the main, just call new WebRequestHandler();

[fabiodiluca]

ericstj is right, I have the same problem here. This is a critical issue on System.Net.Http 4.1.0 that should be repaired. I can't use this library with .net4.6.1 because it lacks consistency.

[dluxfordhpf]

This problem is a significant pain to deal with, and in particularly makes using the Azure KeyVault client painful for my team. The only painless alternative is to downgrade to .NET 4.5.2, which is not acceptable.

Also, the workaround listed previously is insufficient. If you want to use NET 4.6.x, what we've found is you have to do the following this for it to work reliably: disable dependency checking, downgrade System.Net.Http, edit the CSPROJ and disable automatic binding redirect, modify the app.config, and typically clean/exit VS/and rebuild as I've often seen System.Net.Http in use, even for trivial projects. Here's the procedure that reliably fixes this.

1. Right click the project in Visual Studio and select Manage NuGet Packages.
2. Goto the Installed tab.
3. Scroll down to SYSTEM.Net.Http – not Microsoft.Net.Http.
4. In the right hand pane, if Installed is not 4.0.0.0, then set Version to 4.0.0.0.
5. In the right hand pane, set Dependency behavior to Ignore Dependencies. If you do NOT do this, the Microsoft.IdentityModel.Clients.ActiveDirectory package will be substantially downgraded, which is NOT correct.
6. Click Update - this button should really be labeled "Change To Version".
7. In the Preview window, verify that the ONLY change listed is "Installing System.Net.Http". If you forgot to set Dependency behavior correctly, the additional change will be listed here.
8. Click OK/Yes/I Agree on the confirm dialogs and wait for processing to complete. When complete, the package listing will show two version numbers – the check mark is next to the one that is in use.
9. On the NuGet Installed tab, select the listing for Microsoft.IdentityModel.Clients.ActiveDirectory.
10. In the right-hand details pane, set Dependency behavior to "Ignore". If you do not do this, any subsequent NuGet adds will fail when NuGet's validation for this package runs.
11. In Visual Studio, select File|Save All.
12. Open the CSPROJ file for this project in a text editor.
13. In /Project/PropertyGroup*1 (the first PropertyGroup element of Project), add the following line, or change the value of this element if it already exists:
    <AutoGenerateBindingRedirects>false</AutoGenerateBindingRedirects>
14. Save the file, then reload the project in Visual Studio.
15. Open the app.config file for this project.
16. Find the line for System.Net.Http and edit it to redirect it to 4.0.0.0 instead of 4.1.0.0. So find this:

<dependentAssembly> 
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> 
<bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.1.0.0" /> 
</dependentAssembly> 

And change it to this:

<dependentAssembly> 
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> 
<bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.0.0.0" /> 
</dependentAssembly> 

1. Rebuild the project. If you get an exception when running Azure Key Vault code, one or more *.config files in the bin/debug or similar directories have not been updated. You may have to exit Visual Studio to clear them and rebuild.

[fabiodiluca]

dluxfordhpf, thanks for your time explaining how you have worked this out. Redirecting to System.Net.Http 4.0 worked for me in .net4.6.1, But is still very hard to maintain (the nuget dependency). Looking forward the version that will fix this.

[ericstj]

Redirecting could cause problems if folks are using any of the new API added in System.Net.Http 4.1.0.

in particularly makes using the Azure KeyVault client painful for my team

@ChadNedzlek had the same problem and was able to workaround it by passing in an HttpClient he created himself to the KeyVaultClient constructor. If you don't use WebRequestHandler you'll avoid the problem.

EG:

var handler = new HttpClientHandler();
// configure handler
// eg: handler.ServerCertificateCustomValidationCallback = (message, cert, chain, errors) => errors == SslPolicyErrors.None;
var client = new HttpClient(handler);
var kvclient = new KeyVaultClient(async (authority, resource, scope) => "foo", client);

@davidsh I think you need to put AllowPartiallyTrustedCallers back on System.Net.Http.dll. /cc @morganbr

[guillaumeraymond]

@dluxfordhpf Big thanks for the steps.
It is temporary and we hope a fix soon but still, I can continue to work on the project !

[robertmclaws]

@terrajobst This is a blocking production issue. Any idea when we can get a fix onto NuGet? Thanks!

[b3nt0]

Just ran into this myself. Would be awesome if we didn't descend into dependency hell in .Net. It's heading that way.

EDIT: Fixed with a prior comments suggestion to use the system httpclient??
new KeyVaultClient(GetAccessToken, new HttpClient(new HttpClientHandler()))
That seemed to get it...

[MichaelVach]

The problem is only becoming worse as more and more nuget packages from Microsoft take a dependency on the latest version of System.Net.Http. I am probably not the only one who constantly upgrades his Microsoft nuget packages to the latest pre-release version. For example packages that no longer work for me in their latest version:

Microsoft.IdentityModel.Clients.ActiveDirectory
Microsoft.TeamFoundationServer.Client
Microsoft.VisualStudio.Services.Client.
....

[robertmclaws]

I still don't understand why this package is still available. @terrajobst @coolcsh can we get this package taken down/fixed? It's REALLY causing issues with complex app environments. Wasted several hours trying to keep the offending package from creeping into the build. Thanks!

[dluxfordhpf]

We are looking at binding to the System.Net.Http in the NET Framework instead of this broken thing from NuGet. I agree, this problem is ridiculous, and very expensive to deal with as you must synchronize NuGet versions between projects, prevent auto binding updates, and fix/check your app.config. What surprises me is that it’s in such a widely used assembly. Perhaps MS doesn’t really care about KeyVault that much?

[guillaumeraymond]

It is also used by the ActiveDirectory Nugget

[sandersaares]

I have reverted some libraries from targeting .NET Standard due to this and related issues where broken NuGet packages just mess up apps that target .NET Standard. This is a sorry state of things.

[terrajobst]

Thanks for filing. We're actively looking into this. Stay tuned.

[CodingGorilla]

This has become a significant issue for me; we use a lot of our own nuget packages internally. And it seems nuget just will not let those bindingRedirects alone. Everytime we update one of our internal packages, it changes the redirect back to newVersion="4.1.0.0". Is there a way to stop it from doing that, or is there a fix on the horizon?

[mdsharpe]

Encountered when running application over HTTPS, which worked fine over HTTP. Not sure if any other significant differences.
Workaround of setting newversion="4.0.0.0" worked for me.

[jahmai-ca]

Still an issue in NETStandard 1.6.1. Why?!

[LoulG]

System.Net.Http 4.3.0 is out. Someone tried ?

[jahmai-ca]

@LoulG Yep, still a problem I'm afraid.

[robertmclaws]

I spoke with @terrajobst on Twitter, and he said it's actually a bigger problem, and they have like 10 people working on it now. I'm personally not sure why they are not pulling the versions of this package displaying the problem, as I thought that's what package management was for. But the next we can do at this point is wait.

[odinnou]

@LoulG same here, I have updated all my Nuget Packages, with the release of .net core 1.1 and i got this issue

System.TypeLoadException: Inheritance security rules violated by type: 'System.Net.Http.WebRequestHandler'. Derived types must either match the security accessibility of the base type or be less accessible.

Firstly, I think it was due to IdentityServer/IdentityServer3.AccessTokenValidation but, with reading this issue I understand my situation t_t, I spent several hours to try to solve it

EDIT :
OMG,
Workaround of setting newversion="4.0.0.0" worked for me too

I try to update to 4.3 but, same issue :(((

[HalidCisse]

same issue here after upgrading

[vascofernandes]

Issue still present with 4.3.0.

[kwal]

@terrajobst can you provide any updates on this issue or any further insight into the deeper problem that @robertmclaws referenced?

[FenceDad]

Any reason why this fix works locally, but when deployed to an Azure Cloud Service, the error persists?

[jahmai-ca]

Sometimes packaging Azure can screw up your binding redirects, try unzipping the cspkg and see what is actually being deployed.

[FenceDad]

Here is the version of the System.Net.Http.dll

I've been working on this for a few days now. Was super happy to find this fix and in tears when deploying out to Azure.

[jahmai-ca]

What about the .config file containing binding redirects for the project? I actually expect it to still deploy the broken version of the assembly due to CopyLocal being true from the nuget package, but the binding redirect should ensure that the framework version of the assembly is instead loaded inside the cloud service VM.

[FenceDad]

It is!!! WTH?

<dependentAssembly> <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" /> </dependentAssembly>

Looking back into my project, the web.config has reverted as well. I'll have to pick this up again in the morning. Thanks for some leads!

[tofutim]

I also have to thank @chadwackerman2

[georgiosd]

Congrats to all once again for solving one of the most annoying bugs in the history of .NET :)

@karelz happy to do so but I wondered if this is somehow the expected behavior?

[karelz]

@georgiosd I don't know - it will be easier to discuss it in separate issue ;-) (incl. pulling in the right experts)

[gulbanana]

Thanks for driving this work, @karelz

[karelz]

I know I am late with the post-mortem here, my apologies.
I didn't forget, I just didn't get to it yet due to higher priorities (planning/tracking 2.0, looking deeper into the binding redirects issue which surfaced here as well - #17770)
I'll try hard to finish the post-mortem in next 1-2 weeks.

[dmcweeney]

Hi, Well done all involved in resolving this. Cant say I understand all the nuts and bolts but one thing I still don't understand is why this only happened when we upgraded our solution from VS 2015 Update 3 to VS 2017. Solution in question was a set of ASP.Net Core projects targeting the .net framework 4.6. Problem was getting triggered by our use of Azure KeyVaultClient.

Thanks, Donal

[parismiguel]

Hi @karelz , I've been researching and working two nights in a row so far but I'm not able to fix this. All my System.Net.Http packages have been updated to version 4.3.1 but still get the same error. Please help me, I don't know what else to try or where to go. Thanks!

FileNotFoundException: Could not load file or assembly 'System.Net.Http, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.

An here my .csproj

netcoreapp1.1 $(PackageTargetFallback);portable-net45+win8+wp8+wpa81; aspnet-IbmVcaCore-5aa05652-04e7-4a42-9fd6-8dbc1c8b98fe

[karelz]

@parismiguel sorry to hear that :(. Do you have bindingRedirects from 4.0.0.0 to 4.1.1.0 in your app?

<dependentAssembly> 
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> 
    <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" /> 
</dependentAssembly> 

We're looking into how to make the bindingRedirects story smoother: https://github.com/dotnet/corefx/issues/9846#issuecomment-287941109

UPDATE: Looking at your error, it seems that the problem is that your 4.1.1.0 version was not found. Can you check your app directory if the right assembly version is truly there?

[parismiguel]

@karelz that was fast, thank you very much! I've saw the bindingRedirects stuff in previous posts but I'm not sure where to place it... I've tried inside my .csproj but I've got errors (attached as .txt) Concerning version 4.1.1.0 I'm not sure to follow... Am I not supposed to upgrade it to 4.3.1 ?

IbmVcaCore.csproj.txt

[davidsh]

Binding redirects go into your app.config or web.config file:

[davidsh]

See this for details:
https://msdn.microsoft.com/en-us/library/7wd6ex19(v=vs.110).aspx

[parismiguel]

Hi @davidsh , thank you for your help!
My project doesn't have any of those files... its a NET Core project build using Visul Studio 2017 template... what am I missing?

[karelz]

Re: 4.3.1 vs. 4.1.1 - 4.3.1 is NuGet package version, 4.1.1.0 is assembly version (ildasm/ILSpy/VS will show it to you).
The versions NuGet vs. assembly are a bit confusing and it's hard to connect which belongs to which. It's on my list of things to look deeper into if we can connect the dots via documentation (e.g. on NuGet page).

[karelz]

If you're on .NET Core, you don't need the bindingRedirects and moreover, this issue does NOT affect you at all. This issue is specific to Desktop (= .NET Framework).
The 4.3.1 NuGet package modified only its Desktop assembly, not .NET Core assembly.

[karelz]

If you still have trouble, please file a new bug and tag me there. This issue is blasted to quite a lot folks (as it was impactfull), your problem is unrelated to it (at least it looks like that), so let's be kind to everyone's GH notifications / inboxes.

[karelz]

To everyone: I have created a new issue #20777 (was https://github.com/dotnet/corefx/issues/17522) to track the post-mortem I promised.
Sadly, I didn't make much progress towards it yet :( ... but at least everyone interested can start following that issue and avoid potential noise on this issue (trying to help people focus on what they are interested in).

[parismiguel]

@karelz thanks, I'll follow your instructions and post on your brand new issue tracker. Regards.

[karelz]

@parismiguel not on the new issue I created, please create a brand new one. The one I created (#17522) is for post-mortem analysis why this issue (#11100) took so long to resolve.

[parismiguel]

thank you @karelz and my sincere apologies for messing this topic.... hope to get some help in the new one as instructed. Warm regards,

[Workshop2]

I have seemed to have encountered this via a perfect storm.

I am using the Azure Functions preview with a combination of both Azure Key Vault (2.0.6) and Octopus Client (4.15.3).

I have tried upgrading to System.Net.Http to 4.3.2 however it still fails when trying to use Key Vault.

Any tips?

@karelz

[karelz]

Can you please make sure that the assembly from 4.3.2 nuget package is really used at runtime? (it was fixed in 4.3.1)