Re: WPAD ideas and considerations

On 16/03/2014 5:21 a.m., Peter Lepeska wrote:
> 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.

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

Received on Sunday, 16 March 2014 02:17:59 UTC