Re: [hybi] Extensibility mechanisms?

[Adam Barth <[e-mail]>]

On Wed, Jul 21, 2010 at 6:20 PM, Scott Ferguson <[e-mail]> wrote:
> 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.

I don't think you understand how cross-protocol attacks work, and I'm
not that interested in educating you about them.  HTTP POST requests
are also very poorly designed in this way and have been the cause of a
number of cross-protocol attacks, most recently against IRC.

Adam