.NET Core 2.1 SocketsHttpHandler proxy authentication using Windows auth is broken

[bgiot]

When being behind a proxy requesting authentication, .net core 2.1 HttpClientHandler fails to properly authenticate against the proxy. The following code is working in .net core 2.0 but doesn't work anymore with .net core 2.1:

            var handler = new HttpClientHandler();
            handler.DefaultProxyCredentials = CredentialCache.DefaultCredentials;

            var client = new HttpClient(handler);
            var response = client.GetAsync("https://www.mocky.io/v2/5185415ba171ea3a00704eed").GetAwaiter().GetResult();
            var content = response.Content.ReadAsStringAsync().GetAwaiter().GetResult();

[stephentoub]

I ran:

using System;
using System.Net;
using System.Net.Http;
using System.Threading.Tasks;

class Program
{
    static void Main()
    {
        var handler = new HttpClientHandler();
        handler.DefaultProxyCredentials = CredentialCache.DefaultCredentials;

        var client = new HttpClient(handler);
        var response = client.GetAsync("https://www.mocky.io/v2/5185415ba171ea3a00704eed").GetAwaiter().GetResult();
        var content = response.Content.ReadAsStringAsync().GetAwaiter().GetResult();

        Console.WriteLine(content);
    }
}

on both 2.0 and 2.1 on Windows, and on both I get:

{"hello": "world"}

What am I supposed to get instead? What OS are you on? You're using the released version of 2.1 or a preview?

[stephentoub]

When being behind a proxy requesting authentication

Ah, I'm not behind a proxy so my test wasn't valid...

@wfurt?

[wfurt]

What platform and authentication scheme @dotconsulting ?
Best way would be positing full repro I can run.

[bgiot]

Windows world. The proxy requests Windows authentication. I don't know exactly which scheme is used. But for example, with some tools we have to define proxy settings like this : http://{domain\user}:{password}@{proxy}:{port}. I don't know if it helps.

[karelz]

Would it help to get Fiddler/Wireshark traces? To see if we have any proxy info available at all.

[rmkerr]

Yeah, I think Fiddler or Wireshark traces would be really useful here.

[davidsh]

Windows world. The proxy requests Windows authentication. I don't know exactly which scheme is used. But for example, with some tools we have to define proxy settings like this : http://{domain\user}:{password}@{proxy}:{port}. I don't know if it helps.

Putting the username and password in the URL is not supported. It is considered insecure. Our HTTP stacks in general don't support that way for both .NET Framework and .NET Core.

handler.DefaultProxyCredentials = CredentialCache.DefaultCredentials;

The code above here assumes two things. First, that the proxy settings are found via the "default system proxy" settings. On Windows machines, that typically means IE (Internet Explorer) settings. Second, using .DefaultCredentials only works when the proxy supports Windows authentication schemes such as Negotiate or NTLM. If the proxy only asks for Basic or Digest, then .DefaultCredentials doesn't work. You would have to use an explicit NetworkCredential object.

[bgiot]

@davidsh:
Maybe back to the original message i wrote. The code properly works with .net core 2.0 and properly authenticates against the proxy. With .net core 2.1 we receive an "access denied" from the proxy saying no credentials are provided.
the "username and password url" sample was just to provide some hints about how the proxy works.
.DefaultCredentials works with .net core 2.0 but not with .net core 2.1. I think there is a regression bug.

[davidsh]

.DefaultCredentials works with .net core 2.0 but not with .net core 2.1. I think there is a regression bug.

In the short term, you might want to opt-out of the new SocketsHttpHandler HTTP stack in .NET Core 2.1.

See the release notes for instructions on switching back to the HTTP stack (WinHttpHandler for Windows) that was used in .NET Core 2.0:

https://github.com/dotnet/core/blob/master/release-notes/2.1/2.1.0.md

Adding a line of code like this to your app will switch you back to the .NET Core 2.0 HTTP stack:

AppContext.SetSwitch("System.Net.Http.UseSocketsHttpHandler", false);

[bgiot]

I'll try that workaround. I'll keep out posted. Thanks!

[rmkerr]

This isn't a case I considered when writing the default proxy string parser, so if WinHttp supports providing credentials that way there is a regression here.

[bgiot]

@rmkerr:
The issue is with .DefaultProxyCredentials = CredentialCache.DefaultCredentials;
It seems that the credentials (the current logged user) are not passed to the proxy for authentication.

[davidsh]

@dotconsulting

@rmkerr:
The issue is with .DefaultProxyCredentials = CredentialCache.DefaultCredentials;
It seems that the credentials (the current logged user) are not passed to the proxy for authentication.

Can you try an experiment? Instead of using CredentialCache.DefaultCredentials, can you use something like this new NetworkCredential("username", "password", "domain"); ?

Just want to see if the problem is .DefaultCredentials or a generalized problem with Windows Authentication for proxy handling in SocketsHttpHandler? Thx.

[bgiot]

@davidsh
I already tried what you proposed. Same issue when using a specific NetworkCredential instance. I tried also to play with Proxy parameter with a WebProxy class but not better.

[davidsh]

I already tried what you proposed. Same issue when using a specific NetworkCredential instance. I tried also to play with Proxy parameter with a WebProxy class but not better.

Thanks for trying. This looks like there is a bug with Windows Authentication for proxy credentials in SocketsHttpHandler.

To speed up our investigation, is it possible for you to take WireShark traces? I'd like to see if there is actual network traffic attempting Windows authentication (but failing) or just not attempting it at all. Please remove any confidential information from the traces. Thx.