Re: why not WPAD?

------ Original Message ------
From: "Amos Jeffries" <squid3@treenet.co.nz>

>On 2014-01-16 12:59, Adrien de Croy wrote:
>>Hi Peter
>>
>>actually IME the client config is the smallest problem. Usually it's
>>the DHCP, DNS or WPAD.dat http server.
>>
>>DHCP points to the WPAD URL. So, client needs to be using DHCP for
>>starters. Name in the WPAD URL needs to be resolvable to the correct
>>target http server. Target of the URL needs to be running (and on the
>>correct port), and have the WPAD.dat file to serve. WPAD.dat file
>>needs to be correct (no Javascript errors) and point to the correct
>>proxies / ports etc. Initial setup and change-management is
>>burdensome and error-prone.
>>
>>So I'm not sure complete buy-in by client vendors really would help
>>much with this. To get a properly integrated system to do all this
>>automatically would require WPAD-smart webservers that can talk to DNS
>>servers and DHCP servers. DHCP (apart from AD) doesn't have an
>>external mechanism to drive it.
>
>DHCP is effectively optional. If all clients supported the DNS 
>mechanism(s) then DHCP could be dropped and proxies simply use a web 
>server API to update the WPAD.dat files served by the relevant domain 
>server(s).
>
the issue with DNS, is that the URI for the WPAD.dat file becomes fixed 
to http://wpad/wpad.dat

This may or may not work very well for people.

The benefit of DHCP I guess is it allows an admin to specify different 
WPAD URIs to different clients, and also more easily host the WPAD.dat 
file, since the admin can specify the full URI to it.

For many years, WinGate resolved any DNS lookup for WPAD to it's own IP, 
and auto-generated the WPAD.dat file with internal data, and served it 
from the www proxy.

Even then, clients still have problems.

>NP: with an appropriate server script the Squid proxy send_announce 
>mechanism can already to this type of auto-registration.
>
>>
>>Another issue with WPAD compared to a per-connection
>>intercept/enforcement scheme is that it's one-off. The client
>>performs WPAD discovery at the start, and has a static config. After
>>that, it won't alter behaviour.
>>
>
>This is a bigger problem than DHCP. Even the proxy auto-registration 
>cannot avoid this one.
possibly, unless we made it able to cope with this, e.g by allowing a 
proxy to assert that a client must re-configure itself or re-discover 
the proxy or whathaveyou.

Also, it is interesting considering the opportunity for a different 
entity than the proxy (e.g. border router) doing the interception and 
challenging.  This would then allow for features like load balancing 
etc.

>
>On the other hand something as simple as clients properly obeying any 
>Cache-Control/Expires headers on the GET response and re-fetching 
>wpad.dat when it expires would go a long way towards fixing this issue.
Doesn't cope well with outages.  Until the WPAD.dat file expires, the 
client will keep trying the same proxy.

I guess we could all agree that if the proxy was uncontactable that the 
client should re-do proxy auto-detection.

>
>
>>If OTOH you are doing something per-connection, you have the ability
>>to alter/tailor behaviour. For example don't bug the client for
>>certain destination IPs, or source IPs, time of day etc. etc. And
>>this has the opportunity to greatly reduce the number of systems
>>involved and opportunity for errors.
>
>Biggest problem of all IME is the lack of clients supporting WPAD in 
>any form. It is competing with MITM and loosing solely due to this lack 
>of implementations. At the end of the day a network admin correctly 
>implementing all possible WPAD mechanisms still only captures a small 
>amount of the client traffic. Many are deciding the effort is not worth 
>the gain and pick simple MITM despite its flaws.

MITM (and in this case we're talking about plain old TCP interception 
for plaintext http) is the easiest way for an admin to really enforce 
compliance even if it means some things just don't work.  It's one stop, 
you do it in one place and it's done.  By the time it's in play, all the 
other hurdles (e.g. DNS resolution, routing etc) have been cleared.

Adrien


>
>This one will only have a chance at being resolved by fixing the other 
>issues and standardizing WPAD.
>
>Any other known problems with WPAD?
>
>Amos
>
>

Received on Thursday, 16 January 2014 01:20:50 UTC