- From: Adam Barth <w3c@adambarth.com>
- Date: Sun, 24 Jul 2011 10:35:02 -0700
- To: Thomas Roessler <tlr@w3.org>
- Cc: public-ietf-w3c@w3.org, WebApps WG <public-webapps@w3.org>, Salvatore Loreto <salvatore.loreto@ericsson.com>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, 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>
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 Sunday, 24 July 2011 17:36:13 UTC