Re: why not WPAD?

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.

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.

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.

Adrien

------ Original Message ------
From: "Peter Lepeska" <bizzbyster@gmail.com>
To: "Adrien de Croy" <adrien@qbik.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Sent: 16/01/2014 12:39:12
Subject: Re: why not WPAD?

>Adrien,
>
>That makes sense to me -- it's overly complex to deploy and therefore
>prone to failure. As far as needing the client to be configured to use
>proxy auto detect, that might also be the case for the TLS-based proxy
>detection scheme. Also, the TLS-based scheme requires an in-path
>proxy, which sounds like its not an issue for your customers. And it's
>also not an issue for mine, though I think the ability to deploy out
>of path opens up some interesting possibilities. I wonder if you'd
>feel the same way about WPAD if implementors had fully committed to it
>-- if browsers implemented the spec consistently with auto proxy
>detect enabled most of the time. Inconsistent implementation due to
>lack of commitment might also turn out to be a problem with the
>TLS-based scheme.
>
>I'm still not sure that WPAD is fundamentally worse. And plus it 
>already exists.
>
>Peter
>
>On Wed, Jan 15, 2014 at 4:39 PM, Adrien de Croy <adrien@qbik.com> 
>wrote:
>>
>>  Hi Peter
>>
>>  in general, WPAD involves up to 4 different systems.
>>
>>  DHCP
>>  DNS
>>  http server for WPAD.dat URL
>>  client (must be configured to use auto proxy detect)
>>
>>  then there's the Proxy
>>
>>  this is 4 places for failure in the WPAD setup.
>>
>>  We find in practise deploying WPAD to be very problematic for 
>>customers. If
>>  however they could divert ports via the proxy, there's 1 system to 
>>enforce
>>  and advertise the requirements for connection, and it's the proxy.
>>  Therefore the proxy vendor has complete ability to develop and deploy 
>>all
>>  the necessary bits. Neither is it dependent on client config.
>>
>>  Since clients may start their browsing with https, therefore there 
>>needs to
>>  be a way within TLS to advertise this. So actually I think the 
>>approach is
>>  a very good one, and stands to make life a great deal easier for all 
>>my
>>  customers in any case.
>>
>>  Adrien
>>
>>
>>
>>
>>
>>  ------ Original Message ------
>>  From: "Peter Lepeska" <bizzbyster@gmail.com>
>>  To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
>>  Sent: 16/01/2014 08:09:14
>>  Subject: why not WPAD?
>>
>>>  Salvatore's recent draft on trusted proxies
>>>
>>>  
>>>(http://www.ietf.org/internet-drafts/draft-loreto-httpbis-trusted-proxy20-00.txt)
>>>  presents one approach for browsers to learn about the presence of
>>>  proxies, even when the browser is first using HTTPS to talk to the
>>>  Internet.
>>>
>>>  But WPAD already exists for this purpose and all of the browsers
>>>  support it in one form or another -- chrome recently added support 
>>>for
>>>  WPAD over DHCP as I understand it. I know there are implementation
>>>  problems with WPAD and proxy autoconfig but fundamentally what is
>>>  wrong with the approach of leveraging DHCP and DNS to discover 
>>>proxies
>>>  and then relying on a simple javascript-based script to determine 
>>>when
>>>  the proxy should be used?
>>>
>>>  Is there something fatally flawed about the WPAD/PAC model for 
>>>dynamic
>>>  proxy detection? If this topic is covered in another thread, please
>>>  send me a link to it.
>>>
>>>  Thanks,
>>>
>>>  Peter
>>>
>>

Received on Thursday, 16 January 2014 00:00:22 UTC