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

[Maciej Stachowiak <[e-mail]>]

On Oct 11, 2010, at 5:00 PM, Scott Ferguson wrote:

> James Graham wrote:
>> On 10/11/2010 02:28 PM, Greg Wilkins wrote:
>>> 
>> 
>> So there is an underlying issue here that I don't understand. It seems clear to me that Adam and Eric's proposed handshake has a better security story with regard to cross-protocol attacks than -75, -76, or any other proposal other than using NPN with TLS. However there seem to be a number of people who have problems with this proposed handshake to the extent that they are prepared to forgo the security properties in order to get something different. In general people seem to be aware that they are making the security weaker since the arguments are mostly about how different approaches will probably be good enough in practice even though they are theoretically inferior.
>> 
>> What I haven't followed is what the problems with the proposal actually are. I understand that I have likely missed these in other messages, but it would be helpful if people who believe that the proposed approach, or aspects of it, are unworkable could summarise the outstanding issues they see.
> 
> Some of the problems with the proposal:
> 
> 1. auditing - the proposal takes away the capability to audit requests after an attack. Remember, cross-protocol is not the only kind of attack. Server admins will want to track down access logs to find the problem, but the proposal makes these request log opaque to the server admins.

It doesn't take away that capability - just means a WebSocket aware server needs some additional logging code.

> 2. authorization - since the proposal no longer uses URL/method and specifically doesn't use a unique WEBSOCKET method, existing security systems in existing servers cannot be used. (<Limit>, .htaccess, etc.)

For servers that are not modified to be aware of WebSocket, this is true, but probably not very relevant since WebSocket connection attempts will fail. For servers that are updated to support WebSocket, that doesn't have to be true.

> 
> 3. incompatibility with existing host/application dispatch models. In existing servers, the URL/host are used to dispatch to the server before processing. This proposal upends that model, requiring WebSocket to be dispatched before knowing the target resource.

Adam's revised design allows for this, but it would require servers to be updated to decrypt the extra URL and host fields, after which they could be passed through the ordinary dispatch logic.

> 
> 4. performance - the proposal requires encryption of the entire data stream. That's not cheap on the server side.

If AES-128-CR is too computationally expensive (and I really doubt it is), the proposal works fine with simpler ciphers. However, I believe modern server-class hardware can do streaming AES-128 at a rate that would significantly outpace even the fastest network hardware, so I would be skeptical that this is going to be the bottleneck absent some data.

I'm pretty convinced that encrypting the message payload, even if not the handshake header, is pretty much essential, even if it is only dumb encryption like XOR with the key. There is almost no downside and it greatly reduces the attack surface.

> 
> To justify these security, performance, and management penalties, the proposal proposes an attack which requires the target machine to run an attacker program, assumes the target web server is under the control of the attacker, and assumes the target application has an additional open security hole to non-browser clients.

I would put it another way. It replaces security-by-coincidence with a provable invariant. Instead of having to bet that no WebSocket stream will ever happen to look like an understandable part of another protocol, you make sure an attacker using WebSocket can only send a fixed prelude plus what will seem to be random bytes, and a WebSocket service being attacked with HTTP will only see random bytes after decrypting.

Also, the Adam+Eric proposal actually has a significant performance advantage over Greg's proposed handshake, namely fewer round trips. Even if this effect does not dominate today (and I suspect it does), cpu speed grows much faster than network latency shrinks.

Regards,
Maciej