Re: [hybi] New port and Tunneling?

["Shelby Moore" <[e-mail]>]

> Hi Greg,
>
> On Mon, Aug 16, 2010 at 01:09:22PM +1000, Greg Wilkins wrote:
>> Shelby,
>>
>>
>> The concerns I've mostly seen discussed is for an intermediary to pass
>> the handshakes, but then not forward arbitrary data.
>>
>> However,I guess it is possible for a really stupid proxy to inject
>> "HTTP headers" or similar into a websocket stream and corrupt data,
>> specially if the data looked like a HTTP message.    Perhaps that is
>> an argument for a simple checksum in the framing mechanism (previously
>> suggested and rejected because we are not trying to fix problems with
>> TCP/IP - but this is a different use-case).
>
> What could very well happen in fact is that an intermediary does not
> know that "101" requires all the chain to switch to tunnel mode, and
> that it then considers the first data from the client as a second
> request. It will send return "HTTP/1.1 400 Bad Request" in the response,

But what if the data (sometimes randomly) looks like a valid HTTP request,
then all sorts of domino-effect random things could happen?  So every time
HTTP is upgraded with new keywords and syntax, WebSocket is broken!

I suspect this is also a security hole of some sort.

> which does not look like a WS frame at all. That's why I was advocating
> (and Jamie too) for the use of "Connection: close" in the request
> headers. At least the intermediaries will know that they must close
> after the first request is done. That will also improve fast fail on
> incompatible components, because we won't have to wait for sending data.

Are you saying that the very first data sent will be guaranteed to always
be ill-formed HTTP, and so thus we can detect the "HTTP/1.1 400 Bad
Request" _always_ in a fast fail on incompatible components?  But what
about for proxies that always pass through and only take action on HTTP
they want to filter on?  You are making the assumption that every proxy in
the world will issue "HTTP/1.1 400 Bad Request" for a request it does not
understand.  Does the HTTP spec require proxies to reply or is pass
through allowed by the spec?


>
> But I'm not worried for the rest. Having random headers inserted in the
> 101 response is not a problem at all. And I don't see why any data could
> get corrupted at all. At worst we could imagine that some IDS/IPS will
> sometimes believe they see a known bad signature and reset the
> connection as they sometimes do on HTTPS traffic, but there are many
> other reasons for connection that we have to deal with.

If my comments above are correct, take that as flashback to our security
discussion that there is no way you can know your implementation is
"clean".  There are always cases unforseen.  The state machine is too
large to load in the human mind.  We discover specific cases as we come
across a reason to think about or experience them.

>
> Regards,
> Willy
>
>
>