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

[Joel Martin <[e-mail]>]

I must be missing some key concept here because your answers have been what
I already know (and agree with), but they still seem out of sync with the
text of the paragraph.

The draft paragraph is talking about protecting WebSocket servers from
NON-WebSocket clients (i.e. XMLHttpRequest or forms) and implying that the
Sec-WebSocket-Accept somehow helps in that situation. I understand how a
XMLHttpRequest/form submission will not have Sec-WebSocket-Key so this
prevents a WebSockets server from answering a non-WebSocket request. But
what does sending a proper Sec-WebSocket-Accept have to do with this case?
The Sec-WebSocket-Accept value is so that a WebSockets client knows the
server is a real WebSocket server. Won't a non-WebSockets request just
ignore the Sec-WebSocket-Accept?

Regards,

Joel Martin

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

> Historically, many servers are lazy. They will not bother validating
> whatever the client sends, and will just return some value and then get
> exploited. By forcing the server to prove something to the client, we
> essentially also force the server to validate at least part of the client's
> handshake (rather than just hardcoding in some 101 Upgrade WS response). So,
> by making the server prove something to the client, it's a way of forcing
> the server to actually take some steps that have a side effect of protecting
> it (e.g. this /forces/ the server to parse the Sec-WebSocket-Key header.)
>
>
> 2011/6/16 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
>>>>
>>>>
>>>
>>
>