Re: HTTP, websockets, and redirects

What is the rationale for also failing the websocket connection when a response for authentication is received such as:

401 Unauthorized
407 Proxy Authentication Required


On 8/10/11 Art Barstow wrote:

> Hi All,
> 
> Bugzilla now reports only 2 bugs for the Web Socket API [WSAPI] and I would
> characterize them both as editorial [Bugs]. As such, the redirect issue Thomas
> originally reported in this thread (see [Head]) appears to be the only
> substantive issue blocking WSAPI Last Call.
> 
> If anyone wants to continue discussing this redirect issue for WSAPI, I
> recommend using e-mail (additionally, it may be useful to also create a new
> bug in Bugzilla).
> 
> As I understand it, the HyBi WG plans to freeze the Web Socket Protocol spec
> "real soon now" (~August 19?).
> 
> -Art Barstow
> 
> [WSAPI] http://dev.w3.org/html5/websockets/
> [Head]
> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0474.html
> [Bugs]
> http://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&short_de
> sc_type=allwordssubstr&short_desc=&product=WebAppsWG&component=We
> bSocket+API+%28editor%3A+Ian+Hickson%29&longdesc_type=allwordssubstr&
> longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboar
> d_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywor
> ds=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailt
> ype1=substring&email1=&emailtype2=substring&email2=&bug_id_type=anyex
> act&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=d
> oit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-
> 0=noop&value0-0-0=
> 
> 
> On 7/27/11 8:12 PM, ext Adam Barth wrote:
> > On Mon, Jul 25, 2011 at 3:52 PM, Gabriel Montenegro
> > <Gabriel.Montenegro@microsoft.com>  wrote:
> >> Thanks Adam,
> >>
> >> By discussed on some  mailing list, do you mean a *W3C* mailing list?
> > A quick search turned up this message:
> >
> > "But I'm totally fine with punting on this for the future and just
> > disallowing redirects on an API level for now."
> >
> > http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-March/031079.
> > html
> >
> > I started that thread at Greg Wilkins' recommendation:
> >
> > "This is essentially an API issue for the browser websocket object."
> >
> > http://www.ietf.org/mail-archive/web/hybi/current/msg06954.html
> >
> >> Also, allowing the users to handle these explicitly implies that the API does
> not mandate dropping the connection. Currently, the API does not have this
> flexibility, nor does it allow other uses of non-101 codes, like for
> authentication. I understand the potential risks with redirects in browsers, and I
> thought at one moment we were going to augment the security considerations
> with your help for additional guidance. If websec has already worked on similar
> language in some draft that we could reuse that would be great, or, similarly, if
> we could work with you on that text.
> > We can always add support for explicitly following redirects in the
> > future.  If we were to automatically follow them today, we'd never be
> > able to remove that behavior by default.
> >
> > Adam
> >
> >
> >>> -----Original Message-----
> >>> From: Adam Barth [mailto:w3c@adambarth.com]
> >>> Sent: Sunday, July 24, 2011 13:35
> >>> To: Thomas Roessler
> >>> Cc: public-ietf-w3c@w3.org; WebApps WG; Salvatore Loreto; Gabriel
> >>> Montenegro; Art Barstow; François Daoust; Eric Rescorla; Harald
> >>> Alvestrand; Tobias Gondrom
> >>> Subject: Re: HTTP, websockets, and redirects
> >>>
> >>> This issue was discussed on some mailing list a while back (I forget
> >>> which).  The consensus seemed to be that redirects are the source of
> >>> a large number of security vulnerabilities in HTTP and we'd like
> >>> users of the WebSocket API to handle them explicitly.
> >>>
> >>> I'm not sure I understand your question regarding WebRTC, but the
> >>> general answer to that class of questions is that WebRTC relies, in
> >>> large part, on ICE to be secure against cross-protocol and voicehammer
> attacks.
> >>>
> >>> Adam
> >>>
> >>>
> >>> On Sun, Jul 24, 2011 at 6:52 AM, Thomas Roessler<tlr@w3.org>  wrote:
> >>>> The hybi WG is concerned about the following clause in the
> >>>> websocket API
> >>> spec:
> >>>>> When the user agent validates the server's response during the
> >>>>> "establish a
> >>> WebSocket connection" algorithm, if the status code received from
> >>> the server is not 101 (e.g. it is a redirect), the user agent must fail the
> websocket connection.
> >>>> http://dev.w3.org/html5/websockets/
> >>>>
> >>>> Discussion with the WG chairs:
> >>>>
> >>>> - this looks like a conservative attempt to lock down redirects in
> >>>> the face of ill-understood cross-protocol interactions
> >>>> - critical path for addressing includes analysis of interaction
> >>>> with XHR, XHR2, CORS
> >>>> - following redirects in HTTP is optional for the client, therefore
> >>>> in principle a decision that a client-side spec can profile
> >>>> - concern about ability to use HTTP fully before 101 succeeds, and
> >>>> future extensibility
> >>>>
> >>>> Salvatore and Gabriel will bring this up later in the week with
> >>>> websec, and we'll
> >>> probably want to make it a discussion with Webappsec, too.
> >>>> Side note: Does WebRTC have related issues concerning multiple
> >>>> protocols in a
> >>> single-origin context?  Are there lessons to learn from them, or is
> >>> the case sufficiently different that we need a specific analysis here?
> >>>> Thanks,
> >>

Received on Thursday, 11 August 2011 04:37:23 UTC