Re: protocol support for intercepting proxies

mån 2007-06-18 klockan 18:24 +1200 skrev Adrien de Croy:

> I think this has been dragged a bit off topic - I'm sure it's my fault
> for making a suggestion as to "how" instead of sticking to the "why".

And I have only been trying to steer you away from "how", not "why".

Doing network configuration in HTTP is not the right path. Period. There
is other technologies much better suited for the task such as DHCP and
DNS.

> The thing to resolve first of course is the why: is this enough of a
> problem to bother doing anything about?  The what and the how comes after.

Yes.

> My opinion based on fielding support queries on this for the last 12
> years is that it is significant for users of HTTP.

Yes.

> And what are we here for, why do anything to HTTP at all if it's not
> going to in the end benefit the users of HTTP?

Now you walk towards the "how" again..

> Anyway, let's not at this stage assume that this would be an impossible
> problem.

Lets not at this sage consider it a problem of HTTP to be solved by
HTTP. Instead look at the actual problem:

- Admins seemingly lack a reasonable mechanism to get clients to use the
proxy.

In my eyes interception is just a band-aid solution to that problem. If
a real solution to the problem is to be looked for it should be how to
get the client to use the proxy right without having to resort to things
like interception.

The argument that interception is something we have to live with doesn't
hold up as a motivation for adding yet another thing trying to solve
this problem without getting rid of interception.

I would even say it's the use of intercepting proxies which is the cause
to proxy discovery not being fully standardized and interoperable today.
As most admins settle for interception no one demands a well defined
proxy discovery, and instead everyone invests in how to work around the
badness of interception.


> Every parameter you assign with DHCP increases complexity.  After IP,
> Default Gateway, mask and DNS you start to get into areas (e.g. option
> 252) which aren't universally implemented by DHCP servers.  Someone with
> a network set up with manually assigned IP addresses won't benefit from
> DHCP here either, so there are cases where DHCP is a real problem.  Same
> with DNS.  There's no sense to it sometimes, but it doesn't help much to
> tell customers they are senseless.. you tend to lose their business.

And how is adding yet another HTTP extension any different?

> > Oh, indeed, something should be done about it; as you've said, it's
> > common enough in practice. The question is, where is the most
> > appropriate place for that something to be? 
> good question.

And I strongly maintain that HTTP over an intercepted connection is by
no means the appropriate place to communicate proxy settings. For proxy
settings you need a traceable chain of trust to at least the level of
DHCP, and that's not provided by an intercepted connection.

> I personally believe that something should be done to recognise the
> existence of intercepting proxies, and that the main problems that
> exist, such as authentication issues deserve to be looked at.  Whether
> the best solution is something to do in HTTP, or something else is
> another matter, but we shouldn't be prejudiced.

I don't agree this should go into HTTP.

But I am all for making a standardized proxy discovery mechanism if
there is industry interest for it. Main requirement for such task is
that the major browser and HTTP client library vendors is interested.

I am also for documenting the issues with interception, and commonly
deployed solutions to those issues, and the problems with those
solutions. But not as part of the HTTP specifications but rather as a
separate informal document.

> The issues around a client using server vs proxy request semantics (i.e.
> sending full URI, Proxy-Connect, Proxy-Auth tags vs partial URI,
> Connect, and WWW-auth tags) can only be resolved if the UA knows it's
> going through a proxy.

Yes, and not only that it's going through a proxy but also that it can
trust that proxy.

> At the moment, the spec only contemplates explicit proxies (proxies that
> are known about by their clients).

Yes, and that's all the HTTP spec should care about imho.

> So it stands to reason that there is
> a place for an intercepting proxy to upgrade its legitimacy by letting
> the UA know it is there.

As already said RFC2616 requires them to let the UA know it is there.
The standard can't be blamed for proxy vendors not implementing this.
It's already there, adding yet another way for the proxy to indicate
it's presence won't improve the situation, just make it worse.

> As to what happens once a UA learns of the existence of an intercepting
> proxy that is happy to be "found out", that's yet another stage.

Is it?

> Also, as other have said, there are currently some artefacts left in
> communications by intercepting proxies.  Currently there's no UA that I
> know of that lets users know they are going through an intercepting
> proxy.

That's an implementation detail. There is no UA interested in bothering
users with this technical detail which usually has little or no impact
on his experience.

> Another area where the spec could acknowledge the existence of
> intercepting proxies would be to provide guidelines to UA developers in
> 
> a) how to detect the presence of intercepting proxies

I argue that it's already there. Just a matter of making use of the
information already available.

> b) whether or how detected presence of an intercepting proxy should be
> highlighted to the users.

I don't think you will find many in favor of alerting the user..

> However, if everyone feels this is not something that is worth pursuing,
> then fine, I'll carry on doing it my own way, as will every other vendor
> of intercepting proxies, and maybe someone that writes UAs will do
> something, and hopefully we will all drift in the same direction, but
> probably not :)

I hereby call you to look into the problem of why interception is
needed, and to try to come up with ideas to address that problem. In the
long run a proper solution to that problem will benefit you and everyone
else.

Trying to solve this in HTTP is short-sighted and doomed for failure
imho.

Regards
Henrik