Re: [hybi] Upgrade Mechanism and HasMat (was Re: Extensibility mechanisms?)

[Maciej Stachowiak <[e-mail]>]

On Jul 22, 2010, at 5:13 AM, Willy Tarreau wrote:

> On Thu, Jul 22, 2010 at 01:24:54PM +0300, Salvatore Loreto wrote:
> (...)
>> however if HTTP experts exclude any vulnerability in the HTTP Upgrade,
>> then a sort of security check right after the end of the Upgrade from 
>> HTTP to Websocket and before the WebSocket starts to exchange data,
>> could solve the problem.
> 
> We must at least keep in mind that we should avoid round-trips as much as
> possible. For that, I think that Greg's proposal of a nonce in a header is
> particularly interesting because it does not add round trips and can be
> made part of the Upgrade handshake itself. The request and response headers
> could then be advertised in the Connection header just like the Upgrade
> header right now. Such a header could possibly be suggested as general use
> for the HTTP Upgrade mechanism instead of being WS-centric.
> 
> The only fear I have right now with the nonce as defined by the WS draft
> is that it makes use of MD5 which comes with a cost. I know at least one
> site dealing with more than 300k concurrent connections at a rate between
> 12 and 18k per second (long polling right now), and I think that computing
> MD5 hashes can significantly impact performance at these rates. If the
> goal is to ensure the response header depends on the request header, we
> may reliably make use of cheaper algorithms.

I originally suggested computing a hash of the nonce with other data (or some other nontrivial computation) rather than just echoing it back. The goal here is to further reduce the risk of cross-protocol attacks by ensuring that a valid response cannot be constructed solely out of fixed pieces and echoing back portions of the request. I don't think it's essential for the algorithm to be MD5; it does not need to be a strong hash. However, it should avoid having trivial mappings for any values. For example, simply XORing two values is a bad idea because if the attacker can arrange for one value to be 0, the correct response is just the other value with no change. I believe MD5 was chosen because it does not have any such trivial flaws, and is available in popular library implementations. CRC would be adequate for this purpose but is not as readily available.

I think it would be worth doing some math to determine the expense of computing MD5 sums at a plausible connection rate. If MD5 can't keep up with your cited rate of 12k-18k connections per second on the relevant target hardware, then we need to re-evaluate.

Regards,
Maciej