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

[Maciej Stachowiak <[e-mail]>]

On Sep 26, 2010, at 10:35 PM, Greg Wilkins wrote:

> 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.

I don't consider it an insult, rather, an encouragement to learn more about the problem space. I even gave you some pointers on how to learn more (in the part of the message you snipped).


> 
>> 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.

I don't think anyone is suggesting less diligence. I tried to do due diligence on your proposal, but you seem more interested in defending your solution than in learning more about the problem space.

> 
> 
>> 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.

That may be, but you made a security claim about it in your original message proposing it, and appeared to overlook cross-protocol attacks from HTTP to WebSocket, which is why I re-raised that point.

> 
> 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.

I'm not starting with the assumption that the current handshake is adequate, though I think it is slightly stronger than your proposal because the attacker has to control more of the request.

> 
> 
>> 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).

I don't believe that is true. If the attacker is using an HTTP API and has injected the nonce, then the attacker also knows the hash of the nonce, and therefore can produce a pong response with the correct hash without waiting for a response from the server.

Incidentally, I would not stand behind a version of the ping/pong handshake that adds a server-generated random number. Servers at times accidentally use low-quality random-number generators, it would be better not to stake security on strength of a server-side RNG.

> 
> 
>> 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.

I'm not specifically advocating for space counting. I just think your proposed handshake is weak from a security perspective.

> 
> 
>> 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.

When a system provides multiple alternatives that the attacker can choose from, its security is only as strong as the weakest link. If the HTTP-based handshake creates undue risk of cross-protocol attacks, then the availability of a less exploitable alternative will not make the Web as a whole more secure.

> 
> 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.

I've given you input on your proposal. I explained in some detail why I think it is quite weak in the HTTP vs. WebSocket cross-protocol attack scenario. I don't see a substantive response to my comments in your message above. Can you give an argument for why the nonce+ping handshake is well-defended against cross-protocol attacks? I have made a case that it is not very strong, I believe the ball is in your court to show otherwise, regardless of the strength of any other handshake under consideration.

Regards,
Maciej