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

[Gabriel Montenegro <[e-mail]>]

+1 on this handshake. The only comment I'd make is that the server ping does not need to wait for a different message. It can follow the 101, as long as its after the empty line following the 101, as anything at that point is now expected to be websocket protocol and no longer HTTP. 

If there's any fear that the server's hash in the ping could collide with any other protocol's payload, then just add "WebSocket" to the hash in the ping.


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Greg
> Wilkins
> Sent: Thursday, September 23, 2010 12:06 PM
> To: ifette
> Cc: Alexander Voronin; hybi
> Subject: [hybi] Handshake was: The WebSocket protocol issues.
> 
> 2010/9/23 Ian Fette (イアンフェッティ) <[e-mail]>:
> > Greg,
> > I want to point out that I am totally open to replacing the handshake.
> > However, I do think there are a set of requirements that we should meet:
> 
> Ian,
> 
> I never meant to imply that you were not.   You're doing a great job
> and good progress is being made.
> 
> The only thing that I ask is that when we consider all alternative
> proposals that we do not give the current handshake any benefits
> simply due to incumbency that I believe was not obtained with due
> diligence.    We should simply consider all alternatives and pick the
> best.
> 
> 
> So I'll  summarize my ping pong proposal and then discuss the criteria
> you listed below
> 
>  + The client handshake should include a random nonce that the client
> generates after the websocket instance has been created
>  + The server handshakes with a 101 that indicates acceptance of the
> websocket upgrade.
>  + The server then sends as the first message on the connection a ping
> that has a hash of the nonce in its body.
>  + The client recieves the 101 response and then the ping request.
> Only after checking the contents of the ping and sending a pong
> response (to ensure the connection is still open) should it call the
> onopen callback of the websocket object
>  + The server has a ping timeout running that is cancelled by the
> receipt of the pong. If the pong is not received, the connection is
> terminated.
> 
> 
> > 1. Prevent cross protocol attacks. (It would really help if these were
> > enumerated in detail.) If WebSockets can be used to e.g. attack an SMTP
> > server and cause it to send mail, as one example, I think people would turn
> > off / not implement WebSockets, which would not be good.
> 
> The proposal includes a nonce that is generated by the browser after
> the URL is passed.  Thus any injectable server will not be able to be
> attacked with a crafted URL that will trick it into emitting a 101
> response and ping with hash.  So a websocket client cannot be used to
> attack an injectable HTTP server (which I think would still be
> vulnerable to all sorts of horrendous attacks if it were so
> injectable).
> 
> I can't think of a non-websocket server that could not be compromised
> by the current handshake, but could be comprised by the ping pong
> proposal.  The initial bytes of both are substantially similar and
> thus any protocol that accepts a HTTP upgrade request as legal content
> is going to be a problem.
> Wrapping the random bytes in a ping frame will make them less likely
> to match some other protocol, as the random bytes always have a chance
> of picking something that happens to match.
> 
> Thus I think the ping/pong proposal is as least as good as the current
> handshake in this regards.
> 
> 
> 
> > 2. Detect and fail in the presence of intermediaries that will cause
> > problems with the WebSockets connection. If there's an intermediary that is
> > going to be buffering messages for a long period of time waiting for a
> > connection to be closed, as is the case with some current HTTP
> > intermediaries, that would cause serious problems and I would want to know
> > that up front. The current handshake doesn't do a great job here in that
> > it's been pointed out (in Issue 4) that it hangs in the presence of certain
> > such proxies. As I stated in another email, I'm open to alternatives.
> 
> My proposal tests the capability of intermediaries to handle websocket
> messages by sending actual websocket messages.  The client onopen is
> not triggered until the first successful server->client delivery. If
> client->server messages cannot be delivered, that will be detected by
> the pong timeout.
> 
> There is no way to "detect" the non transmission of messages other
> than by having timeouts, plus  Ping/Pong timeouts will need to be
> implemented in any case, so this proposal puts no extra burden on the
> implementations.
> 
> The upgrade response does not need to wait for any non-HTTP data, so
> there is less potential for blocking. The server can send the ping
> (which may fail if an intermediary closes the connection on the 101)
> and then immediately start sending application ws frames while waiting
> for the pong.   The client has to wait for the 101 as it does already,
> and then it can wait for the ping as well.    I assume it already had
> a timeout for the 101 response, so this should not be any extra
> complexity.
> 
> 
> 
> 
> > 3. Compliance with HTTP up to the point of CONNECT.
> > Alternatives that actually meet the above criteria in a manner that is
> > sufficiently "better" than the current proposal I am fully open to.
> 
> The ping/pong proposal is fully compliant with HTTP. Neither endpoint
> sends any non-HTTP bytes until a 101 has been emitted. The bytes then
> sent are actually websocket packets and thus fully respect the terms
> of the upgrade (ie they are not some random bytes that are neither
> HTTP nor websocket).
> 
> 
> 
> 
> There are probably many improvements that can be made to this
> proposal, but I think that it is at least as good as the current
> handshake in all respects and much better in many.
> 
> cheers
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi