Re: [hybi] Extensibility mechanisms?

[Scott Ferguson <[e-mail]>]

Adam Barth wrote:
> On Wed, Jul 21, 2010 at 5:30 PM, Scott Ferguson <[e-mail]> wrote:
>   
>> The counterproposal at
>>
>>  http://hessian.caucho.com/websockets/draft-ferg-hybi-websockets-latest.html
>>
>> not complicated at all: it's a trivial protocol, and yet it solves the HyBi
>> requirements, including requirements that the current draft ignores, as well
>> as being extensible to muxing requirements.
>>
>> A dozen members of this list could come up with proposals as simple as that
>> one and most would improve on it.
>>     
>
> This protocol is highly insecure.  First, the server offers no proof
> that it understands the protocol, so it's very likely that it's
> vulnerable to cross-protocol attacks.  Second, the client doesn't even
> require the server to respond at all before sending (almost) arbitrary
> content over the socket, which is very likely to lead to disaster.
>   
Like I said, most people on the list could improve on it. (Since my 
interest is on the stream encoding itself, I'm perfectly willing to 
defer to others expertise on fixing the handshake.) That said,

1. The server's proof is its initial HELLO control frame. From a 
security standpoint, I don't see how this is different than a HTTP 
server's proof that it understands HTTP. If you want a hash of the 
input, it's trivial to add a nonce header for the client and a 
calculated hash for the response.

1a. How so? I'd like to see an actual attack.

2. No different from HTTP POST. The client may wait for the response if 
it it wants, but clients which want the equivalent responsiveness of 
HTTP POST can send data immediately. It's up to the requirements of the 
application. This design allows both application models.

-- Scott






> Adam
>
>
>
>