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 Sunday, 24 July 2011 17:36:13 UTC