Re: [hybi] Extensibility mechanisms?

[Scott Ferguson <[e-mail]>]

Jamie Lokier wrote:
> Scott Ferguson wrote:
>   
>> Adam Barth wrote:
>>     
>>> On Thu, Jul 22, 2010 at 1:50 PM, Scott Ferguson <[e-mail]> wrote:
>>>  
>>>       
>>>> Adam Barth wrote:
>>>>    
>>>>         
>>>>> We need to know the server understands web sockets before spamming
>>>>> them with attacker-controlled bytes.  If we don't, we'll repeat the
>>>>> long and tragic history of cross-protocol vulnerabilities caused by
>>>>> HTTP POST.
>>>>>
>>>>> This is a hard requirement.
>>>>>      
>> Yes, but that's not specific enough for your requirement because 
>> "consider and mitigate" doesn't necessarily imply "client must validate 
>> server before sending content."
>>
>> As long as everyone's clear and agrees on the "client must validate 
>> server before sending content" requirement, then we're fine.
>>     
>
> It seems a strange leap of logic, as it isn't the only way to mitigate
> the attack risk and it has perceptible negative consequences.
>   

Yes, which is why I thought it important to ask if the delay until 
validation is a hard requirement or not.

IMO, it may be worth spending a little time on proposals like Adam's to 
see if it's possible to reduce the handshake overhead below the server 
validation penalty.

> Anyway I can't see how "client must validate server before sending
> content" can be satisfied.  

Yes. I should have been more precise and said "before frame content".

> Clients are free to encode their content
> in the subprotocol field, and JavaScript apps might actually resort to
> that if it's the only way to hack around that side of the RT delay.
> I'm not sure if the API gives any way for JS apps to retrieve anything
> interesting sent on the other side of the handshake.
>
> Note I have no problem with "client must validate server before
> sending WebSocket encoded frames / dangerous frames / non-HTTP frames
> (take your pick)" .
>   

-- Scott

-- Scott
> -- Jamie
>
>
>
>