Re: [Int-area] New version of WPADNG

[Josh Cohen <[e-mail]>]

Hi David,

Transparent proxies have always been out of scope for WPAD since they are
transparent. I do agree that the vast increase in bandwidth has made
caching largely unnecessary.  It is also true that enterprise tools can
provision proxy information across the fleet; that was true in the late
1990s, at least for Windows / IE.



I'm just getting up to speed on privacy proxy and found this article[1],
which cites tpauly drafts. Is it fair to loosely describe "privacy proxy"
as an HTTP VPN?



Windows 10 and 11 have WPAD on by default.  I think it would be useful to
understand why Microsoft does that before we plan WPAD's funeral.  It may
be that IT Admin customers still want it.  It would also be useful to know
if Apple has telemetry or data on how often it is enabled.



As far as WPAD's security vulnerability advisories, most have been
theoretical rather than real-world occurrences.  However, more recently,
the proliferation of gTLDs has led to actual exploits.[2]



Based on following the advisories over the years, and the recent,
humorously titled "Waiting Patiently for an Announced Disaster"[3] it seems
that the big vulnerabilities are the combination of DNS A + domain
devolution and JavaScript.



My proposal makes some progress on these issues by removing DNS A (along
with other obsolete discovery mechanisms) and including PVD as a modern,
safer config file alternative to JavaScript.



In addition, the use of a URN to explicitly prevent discovery on a network
is helpful.  URNs can probably be used to remove domain devolution
altogether.



One scenario I am curious about is when workers use a proxy in the office,
then take their laptops home where there is no proxy.  How do you see that
being handled in a post-WPAD world?



Hopefully at IETF 120 we can all talk more.





[1]
https://blog.cloudflare.com/building-privacy-into-internet-standards-and-how-to-make-your-app-more-private-today

[2]
https://www.sentinelone.com/blog/in-the-wild-wpad-attack-how-threat-actors-abused-flawed-protocol-for-years/

[3] https://dl.acm.org/doi/abs/10.1145/3565361

On Tue, Jul 9, 2024 at 5:55 PM David Schinazi <[e-mail]>
wrote:

> Hi Josh,
>
> I agree with you that the world has changed a lot since WPAD was defined
> in 1997. The Web has changed, and the use of proxies has changed with it.
> Now that HTTPS is ubiquitous, transparent caching proxies are pretty much
> extinct and proxies are mainly used for either filtering or privacy
> benefits. In both of those scenarios, there exists a trust relationship
> between the client device and the proxy service. And that relationship is
> used to configure proxy settings: modern browsers and operating systems
> offer enterprise controls that allow an administrator to configure a proxy
> on their entire fleet without requiring any automatic discovery. Similarly,
> privacy proxies are configured by the privacy service that runs on the
> client devices. There isn't much of a need for automatic discovery. And
> such discovery causes harm: we've seen time and time again how attackers
> were able to leverage WPAD to gain access to confidential data. Because of
> these two combined factors, many browsers and operating systems have
> disabled WPAD by default. Your WPADNG proposal addresses neither of these
> factors, and doesn't change the fact that WPAD is unsafe and no longer
> needed. At this point in time, I think we can pour one out for WPAD,
> declare that its time has passed, thank it for its service, and move on.
>
> Cheers,
> David
>
> On Mon, Jul 8, 2024 at 5:35 PM Josh Cohen <[e-mail]> wrote:
>
>> Greetings,
>>
>>
>>
>> I've submitted a new draft of Web Proxy Automatic Discovery Next
>> Generation (WPADNG)
>>
>> https://www.ietf.org/archive/id/draft-joshco-wpadng-01.html
>>
>>
>>
>> *Changes:*
>>
>>
>> I've removed the old DNS A TXT, SRV discovery mechanisms
>>
>>
>>
>> The current discovery mechanisms are DHCP (v4/v6), and DNSSD.
>>
>>
>>
>> In terms of priority it is DHCP then DNSSD.
>>
>>
>>
>> For DNSSD the key is new _wpadng._tcp.example.com.  DNS "devolution"
>> remains, eg: first "dev.example.com" then "example.com"
>>
>>
>>
>> I've added the use of a URN for the proxy config URI to indicate "there
>> is no proxy and stop discovery" to prevent discovery of rogue proxies.
>>
>>
>>
>> *I'm seeking feedback on the following:*
>>
>>
>>
>> Is the priority of DHCP, DNSSD best?
>>
>>
>> For DNSSD, is domain devolution common practice?  Eg, eg: first "
>> dev.example.com" then "example.com".    If not, what are other common
>> practices to deal with subdomain scenarios?
>>
>>
>> For DNSSD and DHCPv6, we can include more than just a URL, since we have
>> key/value pairs in DNSSD and from my read, it looks like there is room to
>> do the same for DHCPv6.  Is there other information the client should know
>> that we should add?
>>
>>
>>
>> Are there other URNs that we should add?
>>
>>
>>
>> --
>>
>> ---
>> *Josh Co*hen
>>
>> _______________________________________________
>> Int-area mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>

-- 

---
*Josh Co*hen