Re: HTTP, websockets, and redirects

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, 28 July 2011 00:13:38 UTC