RE: protocol support for intercepting proxies

>-----Original Message-----
>From: ietf-http-wg-request@w3.org 
>[mailto:ietf-http-wg-request@w3.org] On Behalf Of Adrien de Croy
>Sent: maandag 18 juni 2007 8:25
>To: HTTP Working Group
>Subject: Re: protocol support for intercepting proxies
>
>Travis Snoozy wrote:
>> On Mon, 18 Jun 2007 15:15:09 +1200, Adrien de Croy <adrien@qbik.com>
>> wrote:
>>> Travis Snoozy wrote:
>>> <snip>
>>> None of this addresses the fact that
>>>
>>> a) intercepting proxies exist, and exist currently 
>unsupported by the 
>>> spec
>>
[snip]
>>
>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".
>
>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.

As of my experience with an intercepting proxy is that the only trouble
I had run into is connecting to servers that are not on the default
ports (they are blocked, unless using the regular proxy). In general, I
found them very useful as not all (read: too few) applications support
*auto*configuration. Now I can just put my computer on any network and
it just works, yet giving me all the advantages of a HTTP proxy.

In fact, here I have WPAD deployed, but IE gives that annoying
"Detecting proxy configuration" message that really gets on my nerves
everytime I want to do something. But this is an implementation mistake,
not a standard's mistake. Yet again it's a small tradeoff.
Alternatively, the autoconfiguration allows me to override one laptops
corporate policy, where they put in a fixed proxy server that is
reachable from only the corporate network, and not from there. With WPAD
you get arround that and don't have to mess arround with the
configuration everytime you use the browser.

What will in fact be the purpose of knowing that you intercepted HTTP
traffic? In fact, at this point the traffic must already get intercepted
(so it won't solve the non-default ports problem) and there must be a
problem doing so (proxy authentication is desired). And to be honest,
proxy authentication from some magic spot will break automatic tools
anyway and requires configuration. The only types of application that
are capable of handling this situation will be user operated ones.

>My opinion based on fielding support queries on this for the 
>last 12 years is that it is significant for users of HTTP.
>
>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?

+1

[snip]

>> The secondary question is,
>> even if we want to do that something in HTTP, is it reasonably 
>> possible to accomplish it in a sane and secure manner, without 
>> disrupting a substantial portion of the spec? The ternary 
>question is,  
>> might we just write another RFC that specifies the way in which such 
>> proxies (and optionally, user agents) should behave to 
>achieve maximum 
>> interoperability, and simply admit that it's not _really_ HTTP, but 
>> "mostly HTTP compatible"? The final question is, regardless of the 
>> chosen solution, who's going to drive all the work to make sure it 
>> gets done? :)
>these are all good questions, and I think this area is where 
>the discussion should be.
>
>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.
>
>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.

Don't understand Proxy-Connect/Connect.
Thinks only Proxy-Auth is a real problem here.

A good intercepting proxy should know to where the connection attempt
was made and most likely is taken from the host header in all other
cases. In fact, even most servers today rely on the value of the host
header.

>At the moment, the spec only contemplates explicit proxies 
>(proxies that are known about by their clients).  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.  It 
>doesn't matter that some people wont want this feature.  Some 
>people will.  Passing moral judgements over the motives of 
>those who may wish their transparent proxies to remain 
>invisible isn't particularly useful.
>
>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.
>Resolving trust issues allows a proxy-auto-config type 
>benefit, but there are likely other benefits as well.  If you 
>are concerned about the trust issues, try re-working your 
>sample above with more meaningful IP addresses, like in sample 
>1 try using a private IP, and in 2 a public one.  Sure private 
>vs public IPs are crude forms of trust, but given the 
>un-routable nature of private IPs on the internet, it achieves 
>security in the same mechanism as you claim for DHCP.  More 
>trust can be obtained by other methods, say for instance SSL 
>with a certificate.  I think it's too soon to conclude that 
>trust cannot be achieved.

Start quote:
>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?
End quote

So what is going to be the benefit of recognizing the intercepting HTTP
proxy?

>How a UA learns of the existence of an intercepting proxy (i.e 
>standards-based notification vs heuristic forensics) impinges 
>a lot on what can be done with that knowledge.
>
>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.  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
>b) whether or how detected presence of an intercepting proxy 
>should be highlighted to the users.
>
>So, there's 2 areas where I think contemplation of 
>intercepting proxies could provide tangible benefits.  There 
>are probably others.
>
>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'm lacking to see the real benefits at this point. Which doesn't mean
that it can't be useful...

Still I believe the major technical issues, one way or another, is going
to be client support and compatibility. But this is currently not the
point.

- Joris Dobbelsteen

Received on Monday, 18 June 2007 08:29:28 UTC