Subject: WPAD ideas and considerations

From: Amos Jeffries <[email-masked]>
Date: Fri, 14 Mar 2014 17:46:57 +1300

What can we keep and what do we need to get rid of in WPAD?
Please add to this list

WPAD currently has two well-known methods:

1) DHCP assignment

Pros:
 - DHCP ID code already available and well-known
 - simple URI for PAC file works well for those using DHCP on the network.

Cons:
 - ID code limited to URI of PAC file for legacy implementations
 - fixed information. Requires another DHCP allocation to change (or
client to poll the DHCP server)

Things I'd like to see in an upgraded version:
 - ability to avoid PAC and simply point at one proxy FQDN:port the
client is to use.
 People with DHCP should be able use the DHCP server config to send each
network range at proxies relevant to that client range without needing a
PAC to duplicate the information.

2) DNS search

Pros:
 - does not require DHCP
 - can be supported by a wider range of clients more easily than DHCP
 - DNS TTL can be specified to cause refresh of the PAC information at
network admins choice of timing.

Cons:
 - current implementations use a scan of DNS label names for wpad.*
 - several different client algorithms used to scan DNS. At least one of
which is seriously broken.

Things I'd like to see in an upgraded version:

- drop the scan algorithms.
- use of SRV. I propose using _http._pac.local as the FQDN for proxy
identification since _http._tcp should be left for local origin servers.
  This *._pac.local also allows for _ftp.* _https.* or any other
protocols that want to auto-configure a proxy to share the SRV structure.
 => I realise there is the multicast responder problem to work around in
.local. Anyone have a good idea that avoids scanning DNS, mandatory TLS,
or complicated N-way authentications?

Amos

---

From: Peter Lepeska <[email-masked]>
Date: Sat, 15 Mar 2014 12:21:15 -0400

Hi Amos,

I think one important problem with WPAD is that it happens in a way that is
not visible to the user and without their consent. For this reason it is
seen as opening a crack in the door for MITM attackers --
http://it-audit.sans.org/blog/2011/10/03/browser-security-man-in-the-middle-with-wpad
.

In general, one of the reasons why I think we need to tackle the problem of
discovery along with the problem of user consent model is increasingly all
interception proxies are being seen as indistinguishable from MITMs -- and
this is giving us (I work on a transparent proxy) a bad name. In order to
rectify this we should move to a model where we encourage legitimate
proxies to make their presence known both to the user and the content
server. And this requires a new UI metaphor to indicate the presence of
this proxy.

I understand this working group is not chartered to work on UI but I
believe that as part of the information draft on proxies that I believe the
group will soon be taking on we should point out use cases, describe the
problem, and point to some solutions at minimum in the hopes that the work
will be taken up by the appropriate groups afterwards.

Not trying to side track your ideas on improving WPAD but in my opinion the
increased focus on Internet Hardening decreases the likelihood that an
invisible proxy discovery protocol will be enhanced without changes to the
consent model and UI.

Thanks,

Peter

---

From: Amos Jeffries <[email-masked]>
Date: Sun, 16 Mar 2014 15:17:27 +1300

> invisible proxy discovery protocol will be enhanced without changes to the

Mixing interactions between WPAD and trust mechanisms to make them
circularly dependent seems to be what is de-railing all attempts at
improving either part so far IMHO.

WPAD should be naive. Enough to get back both trusted and un-trustable
results.

The trust mechanism, such as an HMAC key exchange in the WPAD messages
or a UI popup. Being a simple yes/no choice defining whether the given
WPAD result is trustable, but not affecting whether WPAD query is asked
or response received.

ie. they should look something like so:
 1) WPAD - find all available proxies, then
 2) VERIFY - figure out which (if any) we can trust, then
 3) TLS - use one in a secure way

Simply finding a proxy does not necessarily mean it has to be the one
used. Neither does authenticating that proxy as trustable.

In fact during all attack cases it is highly likely that a client will
detect multiple proxies and have to determine trust of each. Regardless
of the auto-detect mechanism we decide on.

One cannot simply send off a detection query and guarantee that only the
good guys will respond. So determining how that query is sent and
received cannot rely on security or trust.

Amos

> 
> Thanks,
> 
> Peter
> 
> 
> On Fri, Mar 14, 2014 at 12:46 AM, Amos Jeffries wrote:
>

---

From: "Christian Huitema" <[email-masked]>
Date: Sat, 15 Mar 2014 23:58:30 -0700

> WPAD should be naive. Enough to get back both trusted and un-trustable

Not really. The scenario that you propose would leave a lot of decisions to
be made in real-time by the end users, based on information from insecure
and easy-to-spoof channels. That seems like a recipe for troubles.

We should recognize that "trusting a proxy" is a decision with lots of
potential consequences, and adopt a fail-safe mechanism. For example, having
a set of rules of the form, "if in network N1, use proxy P1, if in network
N2, use proxy P2, if in doubt, do not use any proxy." And then having an
explicit management API to configure such rules. The worst that can happen
with that kind of rule is that the client fails to properly identify the
network, and uses the wrong proxy -- but if will only use a proxy that was
explicitly configured in one of the rules. That is, we may get a performance
hit, but not a security failure.

-- Christian Huitema

---

From: Eliot Lear <[email-masked]>
Date: Sun, 16 Mar 2014 14:47:46 +0100

> and easy-to-spoof channels. That seems like a recipe for troubles.

I think there is probably a middle ground...
> N2, use proxy P2, if in doubt, do not use any proxy." 

How about something like this: this proxy is part of confederations X,
Y, and Z.  If you trust confederations X, Y, or Z, then you trust the
proxy.  Then you don't have to nag the user each time, and it allows for
certification approaches.

Eliot

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Mon, 17 Mar 2014 09:18:18 +0100

> client to poll the DHCP server)

Does not work in most browsers
No trust management in browsers – you enable for your own equipments, if
your users roam you have a big problem
Posits all users on a network use the same pac file of that your control
of dhcp is sufficient to deploy specific rules (and update them every time
user hardware changes…)
Posits a single proxy point of entry – SPOF with no resilience
Huge hassle keeping dhcp, proxy, firewall and local client config in sync
Does basic discovery, says nothing about proxy auth
dhcp handling is a lot less centralised than dns handling

>  - does not require DHCP

yay!

> which is seriously broken.

Can be easily broken by local rent-a-sysadmin DNS servers (aka AD nodes)
with big forced TTLs
wpad* does not really work for complex network topologies
Weird DNS lifetimes in web clients
Weird behaviour when different clients on the same host scan at different
time and get balanced to different equipments
Still requires strong proxy/dns interactions
No pac refresh as far as I know
How do you sync dns ttls with the pac ttl sent in http headers
IPv4/IPv6 usual woes
Does basic discovery, says nothing about proxy auth

Though all of this seems eminently fixable provided the spec is tight
enough to prohibit weirdos.

-- 
Nicolas Mailhot

---

From: Amos Jeffries <[email-masked]>
Date: Mon, 17 Mar 2014 21:37:03 +1300

On 17/03/2014 2:47 a.m., Eliot Lear wrote:
>> be made in real-time by the end users,

No. Simply leaving those decisions to *some* process outside of the WPAD
step.

NOTE the "D" for *detection* in there is a significant scope
differentiator from the followup PAC process with "C" for *configure*.

The end user (if any) may or may not be involved with PAC. And
Authentication if used sohould definitely be part of that decision
making. But should not be relevant to the *WPAD* stage any more than
they are relevant to DNS query responses arriving.

>> based on information from insecure

Sounds good as a step of the PAC process. Deciding which of the detected
proxies is to be used.

Where did the information about said proxy come from though?
 it is the final detail of the WPAD process.

Do you see now what I meant by circular dependencies if the WPAD and
trust are co-mingled?
 one must start by accepting untrusted WPAD response packets *then*
figure out which can be trusted and for what.

AYJ

---

From: Eliezer Croitoru <[email-masked]>
Date: Mon, 24 Mar 2014 03:23:01 +0200

I have not seen information about it yet(maybe missed it) but as I 
remember one thing that was not mentioned was the PAC\DAT file that is 
not re-validated by most if not all the clients while leaving the client 
to use a stale PAC instructions\file.

Which means that the client will not get an updated proxy settings when 
these needs to be verified every 30 secs or every 300 secs.

I am not sure if there was a set of instructions about this issue in the 
RFC documents in the past.

Eliezer