Re: why not WPAD?

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).

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.

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.


> 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.

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:04:52 UTC