Re: protocol support for intercepting proxies

Hi

I see 3 main scenarios for how UA knowledge of intercepting proxies 
could provide benefits, and there are likely more that I haven't thought of.

1. intercepting proxy is also the LAN gateway

This is a common scenario.  The proxy will be on the same network as the 
client, and the client will generally consider the IP of the proxy to be 
trusted.  (i.e. can connect to it without using a default gateway).

* Proxy auto-config can be achieved without requirement for DHCP or DNS 
configuration.
* UA can show some UI demonstrating that the connection is going through 
a proxy.
* By effectively stopping intercepting proxy operation by forcing all 
clients to use explicit proxy semantics, proxy authentication issues are 
resolved.

2. Intercepting proxy at the ISP

This is also common in many countries.

* If there's no gateway proxy, and LAN clients are surfing directly, 
then same as 1, if the ISP proxy can be trusted.  If there is one, it 
would most likely be manually configured to use the ISP proxy if that 
was a requirement of ISP policy.
* a tag could be used to request non-intercepted connection, which could 
be evaluated at the ISP proxy based on policy, and honoured or 
rejected.  This would allow ISPs to provide automatic opt-out of 
intercepted connections, i.e. if a request is received by a client with 
a tag requesting non-intercepted connections, and the ISP proxy is 
configured to honour such requests, then it could action its opt-out 
mechanism for that client.

3. Malevolent intercepting proxy somewhere else

Who knows how common this is.

* UA should warn the user if it detects that a connection is being 
intercepted without explicit notification from a trusted IP range or 
with some other mechanism to establish trust.  If there is explicit 
notification, the warning could be different.

One could argue that there's nothing preventing UAs now from attempting 
to determine if connections are being intercepted transparently and warn 
users if they are being intercepted by agents on IPs outside the local 
LAN.  How to determine where the intercepting agent is heuristically is 
of course difficult and gets more difficult the further (in network 
hops) the IA is from the UA, however there is definitely some use in 
knowing if your ISP (or something beyond) is intercepting your connections.

If the UA is unable to determine that there is an intercepting agent in 
the path, then it's in the same boat it is now.

UAs can then take into account whether an IA (intercepting agent) is 
more or less bona fide depending on how forthcoming it is with 
information about itself, however I'd imagine supporting intercepting 
proxies (notified or not) not on the local network or ISP network is 
unlikely to be useful.

At the end of the day, I'm not proposing we embark on work to make the 
security of the protocol reliant on cooperation and goodwill of agents.  
An eventual goal of this proposal could be to enable enhanced operation 
where agents *can* be trusted to co-operate.  Where there is no trust 
between agents, then of course no proxy auto-config should be performed.

Another goal could be guidelines for UAs about security implications of 
intercepted communications.  UAs warn about everything else (often 
needless, or misguided), a warning about connnections being intercepted 
could arguably be more pertinent than many other things UAs warn / nag 
us about.

The spec continuing to ignore the existence of intercepting proxies I 
don't think does the issue justice, especially since HTTP is probably 
the most intercepted/abused protocol.

Regards

Adrien

Joris Dobbelsteen wrote:
>> -----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 10:38:27 UTC