W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1997

Re: LYNX-DEV two curiosities from IETF HTTP session.

From: Foteos Macrides <MACRIDES@sci.wfbr.edu>
Date: Wed, 10 Dec 1997 20:55:37 -0500 (EST)
To: dwm@xpasc.com
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <01IR0S47BHHE0005K0@SCI.WFBR.EDU>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4895
"David W. Morris" <dwm@xpasc.com> wrote:
>On Wed, 10 Dec 1997, Jim Gettys wrote:
>> >  From: Yaron Goland <yarong@microsoft.com>
>> >  Date: Wed, 10 Dec 1997 11:21:51 -0800
>> >  To: "'jg@pa.dec.com'" <jg@pa.dec.com>, Josh Cohen <joshco@microsoft.com>
>> >  Cc: Foteos Macrides <MACRIDES@SCI.WFBR.EDU>, lynx-dev@sig.net,
>> >          http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>> >  Subject: RE: LYNX-DEV two curiosities from IETF HTTP session.
>> >  
>> >  I doubt any commercial browser will implement 305 without some very serious
>> >  security provided to assure that the proxy asking for the one time redirect
>> >  is going to get it. I would suggest that this problem needs to be dealt with
>> >  in the large 305/306 context, in a stand alone spec, and that the draft
>> >  standard for HTTP should simply state that 305 has been deprecated and
>> >  SHOULD NOT be implemented.
>> >  
>> >  	Yaron
>> I think you are confused....  In Rev-01, only an origin server is allowed
>> to generate a 305 response.  It is authoritative for that resource, so
>But what is there about the protocol which allows this requirement to
>be enforced?
>> the spoofing problems don't come up (and is the reason for that text being
>> in the document...)
>Seems to me that the protocol relies on gentle (i.e., conforming)
>behavior by proxies and servers. The definition of spoofing includes an
>element of malicious intent.
>Perhaps it would close the loop to require that the client only 
>accept a 305 status from an origin server to which it is directly
>Then the potential for spoofing would be limited to IP and/or DNS
>In either case though, I fail to see the motivation for someone
>intending to spoof a redirect who wouldn't simply change the
>origin server or make the IP spoofed variant of the origin server
>simply serve the nefarious content which would have be acquired
>as a result of the redirect.
>Thus I don't see any difference in risk with/without 305.

	The "current practice" is unintended:  The 305 is passed back
to the browser because deployed proxies don't recognize it.

	The 305 *was* intended (I think, but the original discussion
about it was long ago) to be handled by proxies if interposed between
the browser and origin server, in which case it would be the proxy first
receiving a response from the origin server (i.e., what you mean by
"directly connected").  That would be desireable, because for 305 the
browser should not act on it if it already is using a proxy (IMHO, for
security/privacy considerations, and thus how it was implemented in
Lynx).  If proxies do act on it, then it's even more important to make
305 redirection GET-only, because the user of the browser will not be
able to confirm or cancel redirection of a POST.  One can leave 306
redirection of POSTs by proxies as a future possibility (not in the
HTTP/1.1 Draft Standard), but for what it's worth, I've been
scratching my head for some time about how to deal with the
security/privacy problems that would raise, and still don't see any
solutions.  For 305, it's possible that in a chain of proxies the one
which first receives the origin server's response doesn't recognize it,
and passes it on to the next proxy in the chain, but if any proxy in
the chain recognizes it and acts on it with a conversion to GET (if
it's not a GET request in the first place), then there's no security
problem, and no serious privacy problem (certainly much less than with
unverifiable cookie transactions :).


 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
Received on Wednesday, 10 December 1997 18:01:59 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:21 UTC