Re: HTTP, websockets, and redirects

Generally speaking, browsers have been moving away from triggering
authentication dialogs for subresource loads because they are more
often used for phishing than for legitimate purposes.  A WebSocket
connection is much like a subresource load.

Adam


On Wed, Aug 10, 2011 at 9:36 PM, Brian Raymor
<Brian.Raymor@microsoft.com> wrote:
>
> 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 17:20:08 UTC