Re: HTTP, websockets, and redirects

> On Wed, Aug 10, 2011 at 9:01 AM, Arthur Barstow < art.barstow@nokia.com>  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.

As Art notes, the remaining bugs for the WebSocket API [WSAPI] can be characterized as editorial bugs. 

Microsoft has no objections to the requirement to fail non-101 responses such as redirects. If there are no further concerns in the working group related to this issue, then the current WebSocket API looks feature complete. I recommend that we publish a Last Call working draft and define a timetable to reach Candidate Recommendation.

>>
>> 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.ht
>> ml
>> [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_white
>> boar 
>> d_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywo
>> r 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, 25 August 2011 18:31:57 UTC