Re: protocol support for intercepting proxies

Henrik Nordstrom wrote:
> mån 2007-06-18 klockan 10:23 +1200 skrev Adrien de Croy:
>
>> Given that the problem is not going to go away because people are not 
>> going to want to stop using intercepting proxies, wouldn't it be better 
>> if there was some proper protocol support for the concept?
>
> Big fat no from this proxy vendor (Squid). Interception and
> Authentication does not mix, and should not mix.
I've got quite a few customers who would disagree with you on that 
unfortunately.

And quite a few competitors as well.  You'll find most proxy vendors 
that sell their proxies integrated with firewalls etc with packet-level 
capabilities provide interception capabilities, and with auth.  E.g. 
WinRoute, WinProxy, I think ISA server does as well, I'm sure there are 
a whole lot more.

Just because it is bad (imperfect) technically doesn't stop customers 
from wanting it, and therefore vendors from giving it to their customers.

It doesn't work poorly enough to put the customers off it.

>
> What would be better is a standardized proxy discovery mechanism. WPAD
> isn't far from that today, and complemented with a DNS SRV profile it's
> fairly complete for all uses..
>
> And perhaps some way for local networks to tell clients that proxies
> MUST be used.
>
> Doing this in HTTP is just dangerous. Switching to using proxies should
> not be taken lightly as there is security and privacy concerns. Doing so
> in response to messages from random servers without any chain of trust
> to the client is just plain wrong.

Obviously such a mechanism should be used only on the proxy closest to 
the client on the edge of the client's network, so the client would 
trust that proxy.  The gateway would block any such things from outside 
the network, or outside the circle of trust.  For instance many ISPs 
here use intercepting proxies.  Many.  Mainly due to lack of 
international bandwidth, so they save on bandwidth by forcing all 
customers through a great big cache.

Administrators want all issues to be solved in one place.  Having to set 
up SRV records, DHCP options etc etc, WPAD files etc is just adding more 
links to a chain which then gets weaker and weaker.  Support for this 
becomes more difficult.  Competitive forces mean one vendor offers a 
"solution", and the rest must follow or be uncompetitive.  It's all very 
well taking a moral stance on it, but when you start going hungry 
because your customers don't appreciate it, and other vendors are happy 
to provide them what they want, then you start to question whether the 
customers really are wrong.

So like it or not, intercepting proxies, and auth issues is here to 
stay.  I'm just suggesting we should accept that and address the issue 
for the good of the customers.

>
> What could reasonably be done in this area using HTTP interception is an
> error indication which hints the client that it should go and look for a
> proxy if it want's to gain Internet access. But not which proxy. That
> needs to be discovered with some mechanism where there is a reasonable
> chain of trust already established.
>

I agree totally with the trust issue.  But I believe it is possible to 
do this within HTTP

>> UAs at the moment don't generally know if their connections are being 
>> intercepted.  If they knew, then they could;
>>
>> * let the user know connections were being intercepted
>>     - ameliorates issues relating to privacy
>>     - helps users decipher errors better (i.e. upstream connection failure)
>>     - leads towards possible user-control over whether their traffic may 
>> be intercepted or not
>
> This is already in the specs thanks to the Via header.
Many intercepting proxies don't add a Via header, since they wish to 
remain invisible.

If we address intercepting proxies, i.e. allow for them in the spec 
(recognise the reality of their existence), then we could deprecate 
invisible intercepting proxies.

Whilst the spec ignores their existence, it can do nothing about these 
issues.

>
>> * cooperate better with the proxy.
>>     - move to a proxy-oriented protocol operation (can fix many issues, 
>> such as auth)
>>     - deal with errors differently
>
> And this is covered by WPAD (even if just Informal today..).
>
> And without WPAD the UA could in theory extract what it needs from Via
> to switch to proxy operation if desired, provided the proxy actually
> adds what it is required to add to the Via, but doing so would be a
> security nightmare due to the completely missing chain of trust.
>
> Also many doing interception don't want their proxy to send Via because
> they don't want to tell the user which proxy intercepted the request.
> Quite many admins doing the interception dance even asks if it's
> possible to completely hide any proxy generated error messages etc,
> making things always behave as if the proxy wasn't there..
that's impossible, since the TCP connection was already intercepted, and 
therefore the proxy cannot always guarantee it will behave the same as a 
server (i.e. if the server isn't even available, the proxy can't go back 
in time and not accept the intercepted connection from the client).


>
> Regards
> Henrik
Regards

Adrien

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Sunday, 17 June 2007 23:41:33 UTC