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

[Maciej Stachowiak <[e-mail]>]

On Oct 11, 2010, at 2:24 AM, James Graham wrote:

> On 10/11/2010 07:33 AM, Willy Tarreau wrote:
> 
>> Some server farms are shared and other ones are dedicated to some
>> customers, which is the typical scenario we find at almost every
>> hosting provider's, because some customers with very poor code,
>> high traffic or nasty reputations can cause negative side effects
>> on other sites if shared on the same farms. Here, an HTTP content
>> switch (reverse proxy and/or load balancer) will simply look at
>> the host header and forward the request accordingly to the proper
>> server.
>> 
>> With Adam's proposed handshake, this is not possible anymore with
>> currently deployed components. We would have to implement WebSocket in
>> all front components just so that they can decrypt the host header and
>> see what farm is supposed to process it, if any at all. Not only this
>> is not compatible with existing HTTP infrastructure, but doing so makes
>> the frontend component sensible to new DoS attacks because it has to
>> maintain a context before even knowing if it has to handle the request.
> 
> I'm not sure I follow this objection. Unless I am misunderstanding Adam's proposal, all the information needed to access the Host header is in the initial client request; the only additional effort needed is to use the client-sent key to decrypt the headers. According to this understanding, one doesn't have to maintain state across requests just to determine if one will handle the request and, if so, with which back end server.

I agree with this understanding. With Adam's elaborations (not fully detailed in the original proposal), all the routing information is available in the initial client handshake request.

> Is it just the decryption that you believe represents an unmanagable burden?

In the unlikely case that the encryption is an unreasonable burden, I think it's possible to use a trivial form of encryption (XOR with one-time pad) instead of AES-128-CTR. But I think it's probably both safer and typically easier to use a well-known cipher.

Regards,
Maciej