On Fri, 2016-04-29 at 22:20 +0200, Bjørn Mork wrote:
Implementing WPAD via DNS is not our priority now , it comes laterPlease don't. WPAD via DNS is a security nightmare. Have your friendly DNS resolver operator send over some query logs for wpad host names, and you'll quickly realize that there is no end to the attack vectors.
Nevertheless, if we want this stuff to Just Work for us as well as it does for Windows users, then I strongly suspect we're going to have to do *something* with WPAD — horrendously scary though it may be. Perhaps it ends up being a whitelist of domains under which you are permitted to search. So I'd solve things for my users by adding just "intel.com" to the list. Then when it's on the Intel network (and gets intel.com as a DNS search domain), it'll work fine. Perhaps — eventually — we might get a pop-up telling the user that we've discovered a proxy configuration, and *asking* if they want to use it (just this one / whitelist forever). Although I don't like that much. Either way, it wants tying in with the captive portal detection. If we *do* have real Internet connectivity, there's probably no need to bother. But if we don't, and if the WPAD-offered proxy *does* work for accessing our connectivity-test URL, then there's an argument that we should at least *ask* the user if we can use it... Either way, it's not our priority now. It comes later. Let's let Atul get on with the basic plumbing for *handling* this information and feeding it to PacRunner, and we can argue the specifics later for WPAD. -- dwmw2
Attachment:
smime.p7s
Description: S/MIME cryptographic signature