Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt

["Simon Pieters" <[e-mail]>]

On Wed, 15 Jun 2011 02:35:26 +0200, Patrick McManus <[e-mail]>  
wrote:

> On Tue, 2011-06-14 at 22:43 +0000, Gabriel Montenegro wrote:
>
>> Whatever it is, it is best if both RSV and Opcode are handled the same  
>> way (either always fail the connection or always ignore)
>>
>> Does this clarify? Do folks agree that revising to failing in both  
>> cases is fine?
>
> Yes, thanks. (yes both to clarification and failing both).
>
> I've been talking with our security team and they are pretty strongly of
> the point of view that violations of the RSV and Opcode MUSTs need to
> result in failing the connection.

I don't know what the security problem is here, but since extensions are  
agreed upon in the handshake the server has no business using the  
extension if the client didn't ask for it, so failing the connection is  
fine with me.

> That is what we did in our -07
> implementation when the error handling was undefined. Silently redacting
> messages from the application stream by dropping is considered tatamount
> to corruption and is a security risk for the application.
>
> There is a similar reaction to the -08+ requirement that (paraphrased)
> non UTF-8 sequences are interpreted as U+FFFD. Silently rewriting the
> data is frowned on from a security pov. We are considering just failing
> such a non-conformant connection (and I suppose becoming non-conformant
> ourselves by doing so.).

Rewriting broken UTF-8 sequences to U+FFFD is done all over the Web  
platform (exception being XML although most browsers did it in XML too  
until it was tested in Acid3). Failing the connection here seems to make  
the protocol brittle. What's the security problem?

-- 
Simon Pieters
Opera Software