- From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
- Date: Thu, 16 Jan 2014 10:43:15 +0100
- To: "Peter Lepeska" <bizzbyster@gmail.com>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Le Mer 15 janvier 2014 20:09, Peter Lepeska a écrit : > 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. As far as I know there are several problems: 1. javascript: much too flexible, badly supported by web clients, difficult to get right (needs a more restrictive subset that can do less but sanely). I know I will kill cisco voip client should I reorder our pacfile (they choke on some js directives and cisco refused to fix the clients) 2. lack of trusted proxy link and browser support : many security teams will disable by default wpad as there is no technical way to identify trusted proxies and browsers apply wpad silently without giving any feedback to the user about it (making hijacking trivial) 3. wrong layer : it's not in the http exchanges, it's not in the firewall that blocks not-proxified accesses, it's in yet another equipment making deployment hell (and Firefox still refused to do anything with dhcp wpad). The notification really needs to happen in the equipment that refuses not proxified accesses (or redirects to the proxy), in the protocol the web client uses to reach this equipment 4. quite unspecified web client & site behaviour in the presence of several potential proxy paths in the pacfile. Balancing is hell. Regards, -- Nicolas Mailhot
Received on Thursday, 16 January 2014 09:43:45 UTC