Re: WPAD ideas and considerations

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


On Fri, Mar 14, 2014 at 12:46 AM, Amos Jeffries <squid3@treenet.co.nz>wrote:

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