Forcing Browsers To Use A Company Proxy | Your Options

Forcing staff web browsers to use the company proxy is critical for logging and auditing Internet usage and activity. The question is, which method of configuring web browsers to use a proxy is best?

When it comes to configuring web browser proxy setting, we have 4 options:

1. Configure the proxy settings manually or by Group Policy if you’re using Active Directory. With this method you would set the address of the proxy server, the port and select the protocols to include.
2. Use “Auto-detect Proxy Settings“. This method allows your web browser to find the proxy settings from the network. There are some security concerns with this method which we will discuss later.
3. Use “Automatic Proxy Configuration” not to be confused with “Auto-detect Proxy Settings”. This method is basically the same as “Auto-detect Proxy Settings” except that rather than letting the web browser find the settings its self, you tell it precisely where to get them from. This method is safer than “Auto-detect Proxy Settings”.
4. Don’t set anything and use a transparent proxy. This only works for non-SSL/HTTPS connections.

Depending on your requirements, some of the above will be more suitable than others. For example, the “manual” method (option 1) is simple but doesn’t fit well with people and computers moving around. The “Auto-detect” method (option 2) has security issues. The “Transparent Proxy” method (option 4) doesn’t work with encrypted websites (which most are these days). The “Automatic Proxy Configuration” method (option 3) is my pick for today’s networks and businesses.

We will investigate those options in more detail below. We will go through the options in the same order as they appear above.

1. If your computer network is simple and people do not move around with their laptops, the manual option is fine. It is easy to troubleshoot and what you see is what you get. There is no magic (things happening in the background) and you can configure these settings either manually or using Group Policies if you are using Active Directory. However, suppose Sally is working on her laptop in the office and then moves to a coffee shop. Her web browser will not know how to get to the company proxy (unless she is using the corporate VPN) and will eventually time-out and error saying it can’t find the proxy.
2. Using the “Auto-detect Proxy Settings” method comes with great flexibility but some security concerns. Basically what happens is that Sally’s computer boots up and gets IP details (an IP address, gateway address and DNS servers – as well as other things) from the DHCP server. Later Sally opens her web browser. The web browser uses a DNS server to locate the proxy configuration file (called a WPAD file) located on a web server somewhere. It finds it and then uses it to configure the proxy settings. Sally can now surf the web. If Sally moves from the company network to a coffee shop, her computer will get IP details from a different DHCP server that sets her DNS server to something else (such as a public DNS server) so now there are no instructions for her web browser to find a WPAD file. Her web browser will simply fail to auto configure its self and ignore any proxy settings and go straight out to the Internet. The security issue here is that if there is a rogue DHCP server handing out IP details, a hacker could instruct Sally’s web browser to use the hacker’s WPAD file and ultimately force Sally’s web surfing through the hacker’s proxy. That is bad.
3. Using the “Automatic Proxy Configuration” method is an improvement on the above (option 2) method. It is basically the same but rather than using a DNS server to fine the WPAD file, it has the location of the WPAD file manually specified. The WPAD file can be either set manually or by Group Policy if you are using Active Directory.  The security issues of option 2 do not exist with this method.
4. Using the “Transparent Proxy” method is not really an option these days. The idea is that Sally’s computer would not have proxy settings at all but would simply send HTTP requests direct to the gateway which would forward the packets out to the Internet. By replacing the gateway with a proxy server and doing a little tricky fire-walling and port redirection, Sally’s HTTP connection can be transparently put through a proxy. This only works with HTTP but not HTTPS. Trying to push HTTPS through the proxy would break HTTPS and the web browser would complain and error. Do not get confused here, HTTPS can defiantly be put through a proxy but only if the web browser knows about it in advance. With a transparent proxy, the web browser does not already know about it.

Study the above options and pick the one that works best for you. If you have staff moving around with the laptops then option 3 is the best option. If you have a high-security environment where staff do not move around with their workstation, option 1 may be best.

You will often hear about security risks with using the “Auto-detect Proxy Settings” method. We will deal with those concerns here.

1. Sally boots her computer. It broadcasts for a DHCP server and finds one.
2. The DHCP server provides Sally’s computer the IP details that it needs to use the LAN. This includes and IP address, gateway and DNS servers.
   1. This is where the security issue exists. A rogue DHCP server could assign Sally’s computer DNS servers that a hacker owns. We will continue with the walk-through to see how bad this is.
3. Sally logs into her computer and opens her web browser. Her browser checks its proxy settings. It is set to “Auto-detect Proxy Settings” so it asks the DNS server for the IP address for “wpad.example.local” (which is made up of the name “wpad” and the local network’s domain name such as “example.local”). It gets the IP address back “if” there is a “WPAD” entry in DNS.
   1. If the DNS server is owned by a hacker, the DNS record for “wpad.example.local” could point to a web server that the hacker owns.
4. Sally’s web browser then looks for the file “http://wpad.example.local/wpad.dat” and if it’s there, it downloads it. That file consists of some JavaScript that the web browser can interpret and use to configure the proxy settings.
   1. If the web server is owned by a hacker and the WPAD is configured by the backer, the WPAD file could contain malicious proxy settings.
5. Sally tries to visit “www.mybank.com”. Her web browser has proxy settings now and can send requests for the website she is looking for – hopefully her “real” bank.

You can see from the above walk-through that if Sally’s browser is set to “Auto-detect Proxy Settings”, and if hacker has placed a rogue DHCP server on her network, she could find herself sending her web traffic through the hackers proxy server allowing the hacker to intercept her traffic. Obviously HTTPS traffic is safe but there is plenty that still goes over HTTP and also meta data (where, when, etc) can be captured. The hacker could force a pop-up within her web browser asking her to call tech support, for example.

Interestingly Microsoft disables the “WPAD” record in their DNS servers presumably to assist in preventing this scenario. If that is their motivation (I hope not, it doesn’t make sense) it is not going to achieve anything. The issue is that web browsers (specifically Internet Explorer) often default to use the auto detect method so regardless of the availability of the “WPAD” record being available or not on the “good guys” DNS server, the “bad guy” will permit it and any security measure on the DNS server is worthless. The only reasons I can see for disabling the “WPAD” record on the “good guys” DNS server is that that DNS server could be compromised but even then, if it was compromised, it is likely it would be reconfigured to permit the “WPAD” record. One other possibly reason is that if the “good guys” DNS server was not compromised as such but rather had its records poisoned, it would possibly respond to “WPAD” record requests.