The code for WPAD is not network interface aware |
||
Issue descriptionThe code in //net is not generally aware of which network interface requests will be sent out on. This is especially a problem for proxy-auto-detection, which may have differing results per interface. The code in dhcp_proxy_script_fetcher_win.cc [1] seems like a big hack -- it enumerates all of the network adapters that have DHCP, and returns the PAC script from the first one to complete (giving some priority to earlier enumerated adapters) This code has a variety of problems: * Can discovers PAC URL from interface X, but fetching the URL using interface Y (no network interface affinity when fetching the PAC script). * The network interface that wins WPAD isn't necessarily the one that URLRequests will be sent to later * WPAD for each adapter is raced in parallel, so if there are contradictions the final result of WPAD may be flaky. At a minimum, this code should try to restrict itself to the "default" interface. [1] https://chromium.googlesource.com/chromium/src/+/9fb113f6d5363a58168c5ad5c07a7a0dadf921fe/net/proxy/dhcp_proxy_script_fetcher_win.cc#346
,
Feb 7 2018
> so if there are contradictions the final result of WPAD may be flaky. Who tries to actively use multiple networks *with different proxy configurations* concurrently? That sounds crazy. Are there actual use cases? If that happened to me I would like something to notice that and warn me that I'm (for instance) currently interconnecting the company's network with some other one... > the network interface that URLRequests will be sent to later The choice of that network interface is a level 3 routing decision that most applications shouldn't even know about.
,
Feb 7 2018
> Who tries to actively use multiple networks *with different proxy > configurations* concurrently? That sounds crazy. Are there actual use cases? I can't speak to how common this case is, but this bug is marked as low priority to reflect lack of signal. > The choice of that network interface is a level 3 routing decision that most > applications shouldn't even know about. WPAD and proxies change that layering. For instance HTTP proxies bypass name resolution. The only routing decision then is to the proxy server itself. So if you had different PAC scripts to choose from (that in turn can route to different proxy servers), you may end up choosing different proxy servers. You could also end up egressing traffic on a different NIC than that used for deciding WPAD in the first place. After obtaining DHCP option 252 for each of the interfaces, actually fetching this URL is done in an interface agnostic way, so Chrome could fetch a resource from a different network too. If DHCP was advertising a non-FQDN like http://wpad/wpad.dat this is even more likely to break in a noticeable way. The bottom line is that Chrome is selecting which interface to use for that PAC URL prioritized by latency, and subsequent fetches are not interface aware, so the result of WPAD in the multi-interface scenario is unpredictable/broken. @elawrence: Do you know what edge does when multiple interfaces have DHCP?
,
Feb 7 2018
> Do you know what edge does when multiple interfaces have DHCP? Unfortunately, no. I do know that historically, WinINET would utilize the proxy settings from any connected RAS/VPN adapters (in preference over the proxy settings on the DefaultLAN connection). |
||
►
Sign in to add a comment |
||
Comment 1 by mmenke@chromium.org
, Jan 3 2018