[hybi] Handshake was: The WebSocket protocol issues.

[Greg Wilkins <[e-mail]>]

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