Re: [hybi] Websocket: two protocols into one, and Internet rules broken

[Joel Martin <[e-mail]>]

Ian,

I should have been more clear. I understand why the client and server have
to validate each other, it's the text of the paragraph in the draft that I'm
confused about and I posted here because I think the draft text at least
needs clarification.

    "Finally, the server has to prove to the client that it received the
    client's WebSocket handshake, ..."

- Good so far

    "...so that the server doesn't accept connections that are not
    WebSocket connections."

- What does proving to the client have to do with the _server_ refusing
non-websockets connections? Perhaps this is supposed to be "...so that the
client will not procede with connections to non-WebSocket servers."

    "This prevents an attacker from tricking a WebSocket server by sending
    it carefully-crafted packets using |XMLHttpRequest| or a |form|
submission."

- Again, what does proving to the client have to do with tricking the
WebSocket server? Maybe this should really be "This prevents an attacker
from tricking a non-WebSocket server by sending it carefully-crafted
WebSocket packets because a non-WebSocket server will not return a correct
Sec-WebSocket-Accept value during the handshake".

Regards,

Joel Martin

2011/6/16 Ian Fette (イアンフェッティ) <[e-mail]>

> Sec-WebSocket-Accept uses a GUID defined in the protocol and the key from
> the handshake to prove that the remote end is indeed a websocket server as
> you point out. The other part is that Sec-WebSocket-Accept takes the key
> from the Sec-WebSocket-Key header, which XHR cannot send and thus the server
> doesn't have the information necessary to generate the Accept value as there
> is no key from the client.
>
> The original question you link to is basically "why does the server have to
> answer a challenge", and it breaks down into two parts:
>
> 1. Force server to validate that the client is a WebSocket client (by
> making it use a value from Sec-WebSocket-Key along with the GUID, we ensure
> that the server actually checks for the presence of Sec-WebSocket-Key.)
> 2. Let the client validate that the server is actually a WebSocket server
> (by checking that Sec-WebSocket-Accept is properly computed).
>
> #1 lets the server be sure it's not responding to some random XHR request,
> #2 lets the browser know that it's safe to connect and that it's
> communicating to a WebSocket server and not some non-WS target.
>
> On Thu, Jun 16, 2011 at 8:54 AM, Joel Martin <[e-mail]> wrote:
>
>> I started to try and answer this StackOverflow question about the protocol
>> text and realized that I didn't understand it as well as I thought:
>>
>> http://stackoverflow.com/questions/6372252/why-does-the-server-in-a-websocket-request-have-to-answer-a-challenge
>>
>> The question is related to this paragraph (which has been in the drafts
>> for a while unchanged):
>>
>>     Finally, the server has to prove to the client that it received the
>>     client's WebSocket handshake, so that the server doesn't accept
>>     connections that are not WebSocket connections.  This prevents an
>>     attacker from tricking a WebSocket server by sending it carefully-
>>     crafted packets using |XMLHttpRequest| or a |form| submission.
>>
>> I can see how the Sec-WebSocket-Accept would prevent a WebSocket client
>> from being tricked into connecting to a non-WebSocket server. However, I'm
>> having difficulty understanding how the Sec-WebSocket-Accept header would
>> prevent a XMLHttpRequest from succeeding to a WebSockets server since it is
>> sent from the server. I am aware of the prohibition against "Sec-" headers
>> in the client to server direction. Is there a requirement that
>> XMLHttpRequest responses with unrecognized "Sec-" headers be rejected by
>> user agents (and if so does this only apply in the browser case)?
>>
>> It's likely I just don't have enough context to understand the paragraph,
>> but perhaps it could be clarified a bit.
>>
>> Regards,
>>
>> Joel Martin
>>
>> _______________________________________________
>> hybi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/hybi
>>
>>
>