Re: 305 Use proxy

On Thu, 20 Mar 1997, Ari Luotonen wrote:

> Security hole:
> 
> If 305 is allowed by origin servers, intermediate HTTP/1.1 proxies
> that do not understand 305's hop-by-hope requirement will let it
> through (I assume at this point it may be too late to impose the
> hop-by-hop requirement for 305, and expect it to be respected by all
> implementations).  If a client gets a 305 sent by an evil origin
> server through a proxy, it will override the client's proxy settings,
> because the client thinks the proxy redirected it to another proxy.

What is to stop an evil origin server from sending the 305 anyway? If
the proxy doesn't enforce the hop-hop requirement it surely won't do
something special about the evil origin server.

> This security hole can completely cripple people behind a firewall
> where the only way out is through the corporate proxy.  If some evil
> site sends a 305 that goes through to the client, the client will from
> then on try to use a proxy that is inaccessible for it (remember, it
> needs to go thru the company firewall proxy to get out).
> 
> If this security hole is narrowed down by the scope rules, it at the
> same time limits the use of 305 for other uses which I would consider
> more reasonable for 305 -- namely load balancing between proxies, and
> diverting away load from a proxy that is scheduled to go down for
> maintenance.  See below how 305 is not necessary for making
> server-originated proxy redirects.
> 
> Redundant:
> 
> 305 is by no means the only way the client can be instructed to go
> through a proxy.  A regular 301/302 redirect could be used, pointing
> to a "reverse" proxy.  A "reverse proxy" appears as a regular server,
> but is really a proxy when it comes to its content retrieval and
> management.  As far as the client knows, it's an origin server.

Hardly redundant ... a reverse proxy is quite a bit more difficult to
establish as it must explicitly collaborate with the origin server. Also,
each URL to be redirected must first go to the origin server and also all
the way back up the proxy chain.


> from client outward, not by origin servers (because they have no
> knowledge to control the proxy settings of clients).

A lot easier to imagine that a heavily used origin server would know about
geographic proxies and be able to make rough guesses when to redirect
a request to a closer proxy than to imagine an individual user client
having enough information available to identify the proxy.

> Overhead on clients:
> 
> Basically, 305 generated by origin servers implies having to maintain
> a proxy setting for every URL.  This may be tolerable in clients, but

With your reverse proxy approach, it would surely be every URL which had
to be tracked by the client.  The scoping rules allow specification of
proxy for many URLs.

> it's worse on proxies which get a large amount of requests.  Scope
> rules complicate things worse.

Any worse than zillions of 301/2 redirects being sent back thru the proxy
only now the client then sends the redirected request back thru the same
proxy? 

> 
> The reasoning for scope rules is primarily to plug the security hole.

I think just as important is the ability to have clients use different
proxies for collections of servers.

> 
> I would like to get rid of the automatic scope rule restrictions
> altogether, which entails not allowing origin servers not to be
> allowed to send 305's at all, and use a combination of regular
> redirects and reverse proxies instead.
> 
> By virtue of "trusted proxies" you can allow global proxy redirects
> (if scope is not present), which allows *all* requests earlier
> targeted for a given proxy, to be completely diverted to another.

Such redirects need more than scope rules. It should be possible/necessary
to specify the duration of the redirect.


I think proxy management would much better handled by a new HTTP method
via which the client would 'lease' a proxy assignment which might apply to
all requests or some subset.  Use the 305 response type of redirection as
a mechanism for detailed rerouting of requests.  The trusted proxy manager
might even be asked to validate the 305 redirection.

I believe it is reasonable to expect the origin server or a downstream
proxy to know more about how a request should be routed to it. Extending
the response a bit further, perhaps there should be a varies by geography
list of proxies furnished.  The origin server may know the best
alternatives but not what is best for a particular request.

Dave Morris

Received on Friday, 21 March 1997 21:25:48 UTC