- From: Adam Barth <w3c@adambarth.com>
- Date: Thu, 11 Aug 2011 10:18:53 -0700
- To: Brian Raymor <Brian.Raymor@microsoft.com>
- Cc: Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, Thomas Roessler <tlr@w3.org>, Salvatore Loreto <salvatore.loreto@ericsson.com>, "public-ietf-w3c@w3.org" <public-ietf-w3c@w3.org>, WebApps WG <public-webapps@w3.org>, Art Barstow <afbarstow@gmail.com>, François Daoust <fd@w3.org>, Eric Rescorla <ekr@rtfm.com>, Harald Alvestrand <harald@alvestrand.no>, Tobias Gondrom <tobias.gondrom@gondrom.org>
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