Re: Bug#509063: ITP: libproxy -- automatic proxy configuration management library

[Florian Weimer <fw@deneb.enyo.de>]

* Michael Banck:

> On Thu, Dec 18, 2008 at 12:51:34PM +0100, Bastien ROUCARIES wrote:
>> On Thu, Dec 18, 2008 at 12:35 PM, Bjørn Mork <bmork@dod.no> wrote:
>> > Florian Weimer <fw@deneb.enyo.de> writes:
>> 
>> > I would very much like this library to become the *only* WPAD
>> > implementation anywhere.  Hopefully eventually with some ability to
>> > define local policies, where the default Debian policy could be very
>> > strict.  E.g. "Never trust DNS for WPAD", or "Never use WPAD at all".
>> 
>> I tend to agree, we have not forbidden root to do rm -arf .
>> It is the same, it is a policy problem. With current libproxy, could root
>>  forbid the use of WPAD, even if user ask it?
>
> Dan Winship, one of the libproxy authors, replied:
>
> |    - The fact that it's broken doesn't change the fact that lots of
> |      sites use it

I think the question is if there are many sites where you cannot reach
the WWW without performing full WPAD (including DNS devolution).

> |    - It's already implemented by other programs in the distro anyway
> |      (notably Firefox)

This is incorrect.  Firefox does not implement WPAD, according to this
comment in the source code:

        } else if (mProxyConfig == eProxyConfig_WPAD) {
            // We diverge from the WPAD spec here in that we don't walk the
            // hosts's FQDN, stripping components until we hit a TLD.  Doing so
            // is dangerous in the face of an incomplete list of TLDs, and TLDs
            // get added over time.  We could consider doing only a single
            // substitution of the first component, if that proves to help
            // compatibility.

Indeed, the critical part of WPAD is DNS devolution.  (The last
sentence is overly optimistic, though.)

The DNS root operators probably wouldn't want us to roll out Mozilla's
http://wpad/wpad.dat-style partial WPAD, either, because it creates
useless traffic at the root.  Traffic which can't even be offloaded
similarly to the reverse lookups for RFC 1918 by the AS 112 project
because it's well within the security perimeter of the global
Internet.  (Iceweasel doesn't this partial WPAD approach by default,
so we have that covered.)

> |
> |    - Its use in libproxy can be disabled system-wide by the
> |      administrator
> |
> |I think in current libproxy WPAD is enabled by default though. We should
> |make sure that's changed.

The TLD/SLD blacklist in libproxy for DNS devolution is incomplete.
It should use the public suffix list from Mozilla.  Maybe it should
even be split into a separate package, so that it can be updated
separately.

The main risk is that someone has got a computer name like
pc251.example.co.nz, which devolves to wpad.example.co.nz and
wpad.co.nz, the latter being the problem.  There's also a concern
among large organizations that DNS devolution breaks separation of
administrative domains along DNS domains (that is,
deparment1.example.com is affected by a delegation of wpad.example.com
by a second department).

Not enabling WPAD with DNS devolution goes a long way towards dealing
with this mess.