View source for Web Proxy Auto-Discovery Protocol

{{Short description|Ccol}}
The '''Web Proxy Auto-Discovery (WPAD) Protocol''' is a method used by clients to locate the URL of a configuration file using [[Dynamic Host Configuration Protocol|DHCP]] and/or [[DNS]] discovery methods. Once detection and download of the configuration file is complete, it can be executed to determine the proxy for a specified URL.

==History==
The WPAD protocol only outlines the mechanism for discovering the location of this file, but the most commonly deployed configuration file format is the [[proxy auto-config]] format originally designed by [[Netscape]] in 1996 for [[Netscape Navigator|Netscape Navigator 2.0]].<ref>{{cite web
| url=http://wp.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html
| title=Navigator Proxy Auto-Config File Format
| date=March 1996
| archive-url=https://web.archive.org/web/20070307124216/http://wp.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html
| archive-date=2007-03-07
| url-status=dead
| work = [[Netscape Navigator]] Documentation
| access-date=2015-02-10}}</ref>
The WPAD protocol was drafted by a consortium of companies including [[Inktomi Corporation]], [[Microsoft|Microsoft Corporation]], [[RealNetworks|RealNetworks, Inc.]], and [[Sun Microsystems|Sun Microsystems, Inc.]] (now [[Oracle Corporation|Oracle Corp.]]). WPAD is documented in an INTERNET-DRAFT which expired in December 1999.<ref>{{cite journal
| url=https://tools.ietf.org/html/draft-ietf-wrec-wpad-01
| title=Web Proxy Auto-Discovery Protocol (INTERNET-DRAFT)
| first=Paul
| last=Gauthier |author2=Josh Cohen |author3=Martin Dunsmuir |author4=Charles Perkins
| date=1999-07-28
| journal=[[IETF]]
| access-date=2015-02-10}}</ref> However, WPAD is still supported by all major browsers.<ref name="chrome">{{cite web
| url=https://code.google.com/p/chromium/issues/detail?id=18575
| title=Chromium #18575: Non-Windows platforms: WPAD (proxy autodetect discovery) does not test DHCP
| date=2009-08-05
| access-date=2015-02-10}}</ref><ref name="firefox">{{cite web
| url=https://bugzilla.mozilla.org/show_bug.cgi?id=356831
| title=Firefox #356831 - Proxy autodiscovery doesn't check DHCP (option 252)
| date=2006-10-16
| access-date=2015-02-10}}</ref> WPAD was first included with [[Internet Explorer 5|Internet Explorer 5.0]].

== Context ==
In order for all browsers in an organization to be supplied the same proxy policy, without configuring each browser manually, both the below technologies are required:

* [[Proxy auto-config]] (PAC) standard: create and publish one central proxy configuration file. Details are discussed in a separate article.
* Web Proxy Auto-Discovery Protocol (WPAD) standard: ensure that an organization's browsers will find this file without manual configuration. This is the topic of this article.

The WPAD standard defines two alternative methods the system administrator can use to publish the location of the proxy configuration file, using the [[Dynamic Host Configuration Protocol]] (DHCP) or the [[Domain Name System]] (DNS):

Before fetching its first page, a [[web browser]] implementing this method sends a DHCPINFORM query to the local DHCP server, and uses the URL from the WPAD option in the server's reply. If the DHCP server does not provide the desired information, DNS is used. If, for example, the network name of the user's computer is ''pc.department.branch.example.com'', the browser will try the following URLs in turn until it finds a proxy configuration file within the domain of the client:

* <nowiki>http://wpad.department.branch.example.com/wpad.dat</nowiki>
* <nowiki>http://wpad.branch.example.com/wpad.dat</nowiki>
* <nowiki>http://wpad.example.com/wpad.dat</nowiki>
* <nowiki>http://wpad.com/wpad.dat</nowiki> (in incorrect implementations, see note in Security below)

(Note: These are examples and are not "live" URLs due to them employing the reserved domain name of "[[example.com]]".)

Additionally on Windows if the DNS query is unsuccessful then [[Link-Local Multicast Name Resolution]] (LLMNR) and/or [[NetBIOS]] will be used.<ref>{{cite web
| url=http://kb.gfi.com/articles/Skynet_Article/KBID003669
| title=Troubleshooting Web Proxy Auto Discovery (WPAD) issues
| publisher=GFI Software
| access-date=2015-02-10
| archive-date=2021-04-14
| archive-url=https://web.archive.org/web/20210414034409/http://kb.gfi.com/articles/Skynet_Article/KBID003669
| url-status=dead
}}</ref><ref>{{cite web
| url=http://www.netresec.com/?page=Blog&month=2012-07&post=WPAD-Man-in-the-Middle
| title=WPAD Man in the Middle
| first=Erik
| last=Hjelmvik
| date=2012-07-17
| access-date=2015-02-10}}</ref>

== Notes ==

DHCP has a higher priority than DNS: if DHCP provides the WPAD URL, no DNS lookup is performed. This only works with DHCPv4. In DHCPv6, there is no WPAD-Option defined.

When constructing the query packet, DNS lookup removes the first part of the domain name (the client host name) and replaces it with ''wpad''. Then, it "moves up" in the hierarchy by removing more parts of the domain name, until it finds a WPAD PAC file or leaves the current organisation.

The browser guesses where the organisation boundaries are. The guess is often right for domains like 'company.com' or 'university.edu', but wrong for 'company.co.uk' (see security below).

For DNS lookups, the path of the configuration file is always ''wpad.dat''. For the DHCP protocol, any URL is usable. For traditional reasons, PAC files are often called ''proxy.pac'' (of course, files with this name will be ignored by the WPAD DNS search).

The [[MIME type]] of the configuration file must be "application/x-ns-proxy-autoconfig". See [[Proxy auto-config]] for more details.

Internet Explorer and [[Konqueror]] are currently the only browsers offering support for both the DHCP and DNS methods; the DNS method is supported by most major browsers.<ref>{{cite web
| url=http://l10n.kde.org/docs/admin/konqueror.html
| title=Konqueror: Automatic Proxy Discovery
| date=2013-05-20
| work=[[KDE]]
| access-date=2015-02-10
| archive-date=2015-02-11
| archive-url=https://web.archive.org/web/20150211100628/http://l10n.kde.org/docs/admin/konqueror.html
| url-status=dead
}}</ref>

== Requirements ==

In order for WPAD to work, a few requirements have to be met:

* In order to use DHCP, the server must be configured to serve up the "site-local" option 252 ("auto-proxy-config") with a string value of e.g. <nowiki>http://example.com/wpad.dat</nowiki> where "example.com" is the address of a Web server. <!-- Is there any accommodation for IPv6?  maybe http://[dead:beef::cadd]/file.dat format? - fixed csw 2017-11-16 -->
* In order to use the DNS only method, a DNS entry is needed for a host named WPAD.
* The host at the WPAD address must be able to serve a [[Web page]].
* In both cases, the Web server must be configured to serve the WPAD file with a [[MIME type]] of <code>application/x-ns-proxy-autoconfig</code>.
* If the DNS method is used, a file named ''wpad.dat'' must be located in the WPAD Web site's [[root directory]].
* The PAC files are discussed in the [[Proxy auto-config]] article.
* Use caution when configuring a WPAD server in a [[virtual hosting]] environment. When automatic proxy detection is used, WinHTTP and WinINET in Internet Explorer 6 and earlier send a "Host: <IP address>" header and IE7+ and Firefox sends a "Host: wpad" header. Therefore, it is recommended that the wpad.dat file be hosted under the default virtual host rather than its own.
* Internet Explorer version 6.0.2900.2180.xpsp_sp2_rtm requests "wpad.da" instead of "wpad.dat" from the Web server.
* If Windows Server 2003 (or later) is used as the DNS server, the ''DNS Server Global Query Block List'' may have to be disabled, or the registry can be modified to edit the list of blocked queries.<ref>{{cite web
| url=http://www.mpking.com/2010/02/wpad-does-not-resolve-in-dns.html
| title=WPAD does not resolve in DNS
| first=Michael
| last=King
| date=2010-02-17
| access-date=2015-02-10}}</ref><ref>{{cite web
| url=https://technet.microsoft.com/en-us/library/cc995158.aspx
| title=Removing WPAD from DNS block list
| work=[[Microsoft TechNet]]
| date=26 September 2008
| access-date=2015-02-10}}</ref>

== Security ==

While greatly simplifying configuration of one organisation's web browsers, the WPAD protocol has to be used with care: simple mistakes can open doors for attackers to change what appears on a user's browser:

* An attacker inside a network can set up a DHCP server that hands out the URL of a malicious PAC script.
* If the network is 'company.co.uk' and the file <nowiki>http://wpad.company.co.uk/wpad.dat</nowiki> isn't served, the browsers will go on to request <nowiki>http://wpad.co.uk/wpad.dat</nowiki>. Before the introduction of the [[Public Suffix List]] in the 2010s, some browsers could not determine that wpad.co.uk was no longer inside the organization.
* The same method has been used with <nowiki>http://wpad.org.uk</nowiki>. This used to serve a wpad.dat file that would redirect all of the user's traffic to an internet auction site.
* ISPs that have implemented [[DNS hijacking]] can break the DNS lookup of the WPAD protocol by directing users to a host that is not a proxy server.
* Leaked WPAD queries could result in domain name collisions with internal network naming schemes. If an attacker registers a domain to answer leaked WPAD queries and configures a valid proxy, there is potential to conduct man-in-the-middle (MitM) attacks across the Internet.<ref>
{{cite web
| url=https://www.us-cert.gov/ncas/alerts/TA16-144A
| title=Alert (TA16-144A) WPAD Name Collision Vulnerability
| date=2016-10-06
| work=[[US-CERT]]
| access-date=2017-05-02}}</ref>

Through the WPAD file, the attacker can point users' browsers to their own proxies and intercept and modify the WWW traffic of everyone connected to the network. Although a simplistic fix for Windows WPAD handling was applied in 2005, it only fixed the problem for the .com domain. A presentation at [[Kiwicon]] showed that the rest of the world was still critically vulnerable to this security hole, with a sample domain registered in New Zealand for testing purposes receiving proxy requests from all over the country at the rate of several a second. Several of the wpad.tld domain names (including COM, NET, ORG, and US) now point to the client loopback address to help protect against this vulnerability, though some names are still registered (wpad.co.uk).

Thus, an administrator should make sure that a user can trust all the DHCP servers in an organisation and that all possible wpad domains for the organisation are under control. Furthermore, if there's no wpad domain configured for an organisation, a user will go to whatever external location has the next wpad site in the domain hierarchy and use that for its configuration. This allows whoever registers the wpad subdomain in a particular country to perform a [[man-in-the-middle attack]] on large portions of that country's internet traffic by setting themselves as a proxy for all traffic or sites of interest.

On top of these traps, the WPAD method fetches a JavaScript file and executes it on all users browsers, even when they have disabled JavaScript for viewing web pages.

== References ==
{{Reflist}}

== Further reading ==
* {{cite web
| url=http://jdebp.eu./FGA/web-browser-auto-proxy-configuration.html
| title=Automatic proxy HTTP server configuration in web browsers
| work=Frequently Given Answers
| author-first=Jonathan
| author-last=de Boyne Pollard
| year=2004}}

* {{cite web
| url=https://www.microsoft.com/en-us/download/details.aspx?id=8219
| title=DNS Server Global Query Block List
| author=Jim Groves
| website=[[Microsoft]]
| date=November 2007}}

* {{cite web
| url=http://www.findproxyforurl.com
| title=PAC File & WPAD Examples
| date=2015-09-18}}

{{Internet Explorer}}
{{Web browsers}}

[[Category:Internet Explorer]]
[[Category:Web browsers]]
[[Category:Proxy servers]]
[[Category:Computer configuration]]
[[Category:Internet Standards]]
[[Category:Domain Name System]]
[[Category:Service discovery protocols]]