Re: [hybi] Handshake was: The WebSocket protocol issues.

[Alexander Voronin <[e-mail]>]

Let's see whats happen when we using WebSocket:
1. JavaScript creates socket


var webSocket = new WebSocket('ws://localhost/echo');


2. Browser here can't send any kind of data, but just handshaking

GET /echo HTTP/1.1
Upgrade: WebSocket
Connection: Upgrade
Host: example.com
Origin: http://example.com
WebSocket-Protocol: sample

---

HTTP/1.1 101 Web Socket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
WebSocket-Origin: http://example.com
WebSocket-Location: ws://example.com/demo
WebSocket-Protocol <http://example.com/demoWebSocket-Protocol>: sample


3. Just now after browser GOT 101 and correct handshake data we can sand
some data

webSocket.send ("some data that ca not be placed in other than HTTP stream");


So You still think there is posible to "protect" something with MD5, BIG
ENDIAN, or some other kind of ugly string manipulations? Handshake must be
simple and clear just to ensure this is correct HTTP server/proxy and it's
compatible with WebSockets. Before that browser will not allow JavaScript to
send ANY data.

2010/9/24 Willy Tarreau <[e-mail]>

> On Fri, Sep 24, 2010 at 05:50:57PM +0300, Alexander Voronin wrote:
> > Intermediates and servers that have no WebSockets support will answer to
> > handshake with any code but no 101. Is that still not enough to figure
> out
> > if WebSocket connection established? Why to make things complex if they
> > could be simple?
>
> I think that the point that you missed is that since WS works on top of
> HTTP, any HTTP-compliant intermediary will implicitly support WS. However,
> we're aware that there are some incomplete HTTP implementations, and some
> intermediaries which by design will not let that pass through, reason why
> it's important to detect failures quickly.
>
> > Also I did not get this
> > article<http://www.ietf.org/mail-archive/web/hybi/current/msg04166.html
> >by
> > email, but will answer here. Referenced document provides sample of
> > cross-protocol attack using HTTP POST on SMTP. POST is a one-stage
> request
> > without handshake, WebSocket is a GET extension with handshake, so I
> guess
> > does not matter how complicated handshake will be if browser not obey
> HTTP
> > rules and continue HTTP session after getting "500 Command unrecognized"
> > instead of "HTTP/1.1 101 OK". This is not protocol but browser issue.
>
> No, the issue happens before. Imagine that the browser sends an HTTP-based
> handshake immediately followed by a certain amount of bytes that are to be
> understood by the remote server. If that remote server simply ignores the
> handshake because it does not understand it (as most services do), it will
> start to process the rules that follow the handshake. An SMTP server might
> very well accept spam that are sent as a POST request (my mail server
> receives hundreds of those every day).
>
> Whether the browser stops or not when receiving the "500 Command
> unrecognized"
> is irrelevant to the problem, the harm has already been done.
>
> Willy
>
>


-- 
когда я опустился на самое дно, снизу мне постучали..