Re: 305 Use proxy

In message <199703202122.NAA03558@step.mcom.com>, Ari Luotonen writes:
>Let me elaborate on these issues one by one.
>
>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.

I don't know of any clients that have implemented 305.
Is it already in the Navigator (or other browser)?

>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).

And the company firewall let a 305 response go through?  And nobody noticed
being "crippled"? And it took them how long to update their own proxy?
This does not fit my definition of a security hole.  It fits my definition
of a note to add to the security section, but that's all.  In any case,
you would have to implement protection from this "hole" within the
user agent, and I see no reason why it can't be configurable.

>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.

It's a gateway. Please strangle the person who came up with "reverse proxy."

>This has benefits: the real origin server is completele hidden, the
>users will never have to know about its existence.  Also, it keeps the
>design cleaner where origin servers are origin servers, regarless the
>implementation style (regular, replicated, reverse proxy); and proxies
>remain a part of the transport mechanism which is controlled by a flow
>from client outward, not by origin servers (because they have no
>knowledge to control the proxy settings of clients).

It also doubles the number of network requests (the 301/2 isn't free),
relies on URL mangling to make requests, and completely breaks cookies
if the gateway covers multiple domains.  Such a solution only works on
the individual corporate scale, whereas we are talking about proxies
covering Universities or regional/national networks that exist to prevent
an unnecessary network request from going outside their own network.

Keep in mind that the client may think it is talking to the origin server,
but the 305 response may actually be coming from a network firewall.

>Mudding the architectural design:
>
>See above paragraph.

The architectural design of HTTP/1.1 is described in the introduction
of RFC 2068.  It includes understanding of proxies and gateways.

>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
>it's worse on proxies which get a large amount of requests.  Scope
>rules complicate things worse.

They are never forced to maintain that information, but doing so for the
most-recently-accessed servers will be to their own benefit.

>The reasoning for scope rules is primarily to plug the security hole.
>
>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.
>With auto-scope-rule-restrictions this would be next to useless,
>because every new site (at least) would require a new hop by the
>original proxy, just to get a new proxy redirect.

The reason for the scope rules is to broaden it from the current
definition of 305 applying to one and only one URL.  I see no reason
why scope="http" should be impossible, provided the proxy is trusted,
so I see no basis for this objection.

>Conclusion:
>
>I would definitely like to have a proxy redirect that can be generated
>by a proxy only.  If people can come up with examples where 305 from
>origin servers is the only way to accomplish something that couldn't
>be done with regular redirect combined with a reverse proxy, then
>maybe we could have two separate proxy redirections:
>
>    305 Use proxy	-- use proxy, generated by origin servers
>    306 Proxy redirect	-- use another proxy instead, gen'd by proxies only

That would serve no useful purpose -- old proxy implementations will be
updated long before we have any large-scale use of 305, and a user agent
is fully capable of querying the user before obeying a 305 redirect
received from an origin server, if such a thing is a concern.  The user
agent does, after all, know whether or not it is talking to a proxy.
None of this stops people from using gateways as well.

If a new client is installed behind a network firewall and improperly
configured to make direct network requests, then the firewall can detect
those requests and immediately reconfigure the client (with the user's
acquiescence) to use the appropriate proxy, if and only if an HTTP
origin server is allowed to send 305 redirects.  This may in fact be
the only function of said "firewall".


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92697-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Sunday, 23 March 1997 08:17:19 UTC