Re: protocol support for intercepting proxies

tis 2007-06-19 klockan 12:48 +1200 skrev Adrien de Croy:

> Why they wanted it, I guess is because proxy auto-detect or proxy 
> operation wasn't doing it for them. 

That's my guess as well, and I propose fixing that instead of trying to
work around it by adding yet more questionable "hacks".

> However, proxy auto detect can require some configuration.

So will whatever HTTP extension signaling this on a transparently
intercepted connection. For a starter it's quite unlikely to be enabled
by default due to the security implications of not having a reasonable
chain of trust.

> Originally 
> proxy auto-detect worked by doing a DNS lookup for the name "WPAD".  
> WinGate's DNS server would respond to this with its own IP address.  The 
> client would then make an HTTP request for a file called wpad.dat.  We 
> would auto-generate this and send it to the client.  So, basically 
> customers got proxy auto-detect for free.  I presume other vendors 
> adopted a similar approach.

Yes. Well, it's using the normal DNS domain search list from what I can
gather.. But I suppose that if the clients is configured without a DNS
domain then you'll get lookups for just "wpad".

> then someone at MS decided DHCP would be a better option for discovering 
> proxy config, and option 252 was created whereby the DHCP client issues 
> a request for option 252 as part of a DHCP_INFORM message.  DHCP_INFORM 
> was a late addition to the DHCP spec, also option 252 is still listed by 
> the IANA as "private".  So there are a bunch of DHCP servers out there 
> that don't support DHCP_INFORM nor option 252.

It's also usable in the DHCPOFFER, and is where it's normally used.

DHCPINFORM is mainly for hosts not using DHCP for the IP configuration
but still needing the additional configuration details from DHCP. It's
DHCPREQUEST minus the IP allocation and lease checks.

> finally, enabling or disabling proxy auto-detection is under user 
> control.  Heaven forbid!

Don't see it as a protocol problem. Administrators have loads of tools
to control this is they desire. Sure, requires administrators to
actually care about their environment and locking down the users
preventing them from doing (in his opinion) stupid things, but is not a
protocol issue.

> I'm not aware of any browsers that do a sanity check on the values that 
> get returned from a WPAD DNS lookup, or the URL from DHCP option 252 
> either.  We just presume that the DNS and DHCP server responses are 
> trustworthy.

Yes.

> So in short, IMHO proxy auto detect is fraught with problems.

On the local LAN yes, but it's confined there. And if the LAN is
upgraded with DHCP security or DNSSEC then WPAD also benefits from that.


> There are zillions of applications out there that use HTTP for whatever 
> purpose.  Many of these are cobbled together.  Many do not consider the 
> existence of proxies at all, or can't do proxy auth, or any sort of HTTP 
> auth.  Many do not present any UI, but operate as background service 
> processes.  Thankfully with APIs like MS INETAPI on Windows, developers 
> now have an easier way to write such things, and they gain support for 
> things like chunking, auth etc.  But there are still a bunch of broken 
> apps out there.

And there will always be. Adding yet another extension for proxy
discovery won't help that at all.

> Couple this with the sys admin that still wants to force everything 
> through the proxy anyway, and your only option is connection 
> interception, where the proxy pretends to behave like a server (right 
> down to the header level).

It's not the only option. There is several ways of enforcing the use of
a proxy. Interception is the most common as it doesn't require much
thinking to deploy.

> Many of these apps are very old, and aren't being maintained, but are 
> still in use and relied on.

Yes, and will with an absolute certainty not be upgraded to support any
new extension either, so I don't get why you bring this up in the
context of extending the awareness of intercepting proxies.

> If we could assume that all HTTP agents could work through a proxy

You can, by the specs.

> and 
> do proxy auth

Optional, and unrelated.

> we should be looking at a more foolproof mechanism for 
> proxy auto configuration.

Yes.

> The form that takes has many possibilities, 
> you don't like the one proposed so far, that I can live with.

Good.

> But there 
> are potentially others that would solve concerns, and achieve the goals 
> of minimum impact on other systems.

Sure. And what I think efforts should be focused on.

In my view the DHCP track is pretty good even if WPAD has it's
limitations. SLP is also reasonable but less common.

> The fewer the links in the chain 
> IMO the better.

Yes, but there needs to be a traceable chain.

>   So firstly I think such a mechanism should be
> 
> 1. under network not individual control (so the network can set the 
> requirement to use the proxy, not the client, and it can be managed 
> centrally).

Yes, which calls for DHCP as it's the closest to the network level..

> 2. not reliant on DHCP.  Why must we force everyone on the planet to use 
> DHCP just to get an auto proxy config.  Why must we force all OS vendors 
> to open up their DHCP clients so that applications can obtain DHCP 
> configuration data.

DHCP is the accepted standard for local LAN network configuration
distribution.

> So maybe DNS SRV records are the way to go here.  Some customers lock 
> down even DNS though, since the proxy does the DNS lookup for normal 
> proxy operations.

No problem to run a small internal DNS in such networks, and many do.

> Also most OS provided DNS resolver implementations 
> (i.e. winsock) only support A record lookups, so unless you want browser 
> authors to write their own DNS resolvers (and deal with the 
> configuration issues around that), they won't have much luck on many 
> OSes even getting a SRV record.

Correct. For manual SRV lookups you need to use a DNS client, not an
abstract socket interface.

In Windows this is the DNS Functions..
http://msdn2.microsoft.com/en-us/library/ms682058.aspx

Regards
Henrik