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

[Greg Wilkins <[e-mail]>]

Maciej, Adam,


On 27 September 2010 14:35, Maciej Stachowiak <[e-mail]> wrote:
> If you don't understand the risks, then I am not sure you are in a good position to propose solutions or evaluate their effectiveness.

Please stop using insults of my suitability to partake in this
discussion as substitutes for reasoned discussion.


> Many in this WG seem to discount the importance of security risks that they do not personally understand.

Please don't suggest that I do not take security issues seriously or
that by proposing amendments to the handshake that I am somehow trying
to weaken the protection against cross protocol attacks.

> One thing I have learned is that it is very risky to have a defense that just barely works.

Something that many have not learnt is that having something that
looks secure, but has not been subject to rigorous due diligence, is
often highly insecure.


> The reason I am skeptical of your proposed ping-poing handshake as a defense
> against cross-protocol attacks is that the *only* defense protecting WebSocket servers
> from attacks over HTTP is the assumed inability of browser-hosted HTTP clients to send
> whatever carries the random nonce, or something that looks sufficiently similar.

Well the ping pong proposal is actually not addressed at cross
protocol concerns.   The ping pong proposal is focused on the supposed
"fast fail" detection of intermediaries that do not support websocket.

With regards to the defence against cross protocol attacks, the only
change of substance that I have suggested is the removal of the space
counting and random character injection in the keys transmitted.   I
have suggested that the hashed response is carried in a websocket ping
rather than as unframed data, but I do believe that changes the
security nature of the issue (as any server that allowed the injection
of 16 random unframed bytes would surely also allow the injection of a
valid ping frame containing those bytes).

Thus the ping pong proposal carries essentially the same protection
against cross protocol attacks as the current handshake:

1) Standard in browser HTTP mechanisms are unable to generate the Sec- headers
2) The nonce is generated after the Websocket object is created - and
changing it's encoding from char injected space divided strings to hex
makes no difference.
3) Standard clients will be unable to generate the required pong
response, just as they cannot generate the 8 random unframed bytes.


> A potential improvement would be to require the server to produce a random number,
> which is included in the ping and must be in the pong in addition to the hash. In that case,
> an attacker could not queue up the correct pong without looking at the server's response at all.
> But going down this road results in increasingly elaborate schemes, along the lines of the -76 handshake.

Great - a real technical proposal! The pong message is already
required to contain the contents of the ping, so it is already not
possible for a pong message to be simply queued (the attacker has
neither the capability to send the bytes, nor the knowledge of what
they should be).


> It's also likely there are more complicated flaws that we simply haven't thought of yet. I don't think we can
> stake the security of this protocol just on our own ability to think up attacks within a period of only a few weeks.

Where have I suggested that we adopt the whack-a-mole approach of
dealing with only specific known attacks.

I've have been talking about general capabilities that an attacker may
have (eg what kind of bytes sequences they can generate on the wire)
plus the general limitations on what an attacker may know (eg
predicting nonce values, access to cookies etc.).     We then have to
evaluate if the presence of websocket in a browser or server gives an
attacker any additional capabilities or any additional knowledge that
may contribute to any kind of attack.

It is not sufficient to simply say that cross protocol is really
complex and scary an that any attempt to remove the space counting
from the handshake is bound to open up a whole range of unknown and
unforeseeable  security problems.


> As I have thought about these issues, I am increasingly convinced that an NPN-style solution is much more robust.

Indeed it is, and I fully support efforts to standardize that as
another way to establish websocket connections.

Meanwhile we have some real proposals to establish websocket
connections via a HTTP upgrade.  Can we please discuss this and the
security implications of it.  If we are unable to come up with a
reasoned and explicable security model for websocket, then the IETF
processes will not allow any of our proposals progress.