Re: [hybi] New port and Tunneling?

[Greg Wilkins <[e-mail]>]

Shelby,

I believe that we need to consider multiple ways to establish
websocket connections: HTTP upgrade, dedicated ports, TLS next
protocol etc.
We should flesh them all out and then we can make the decision if we
recommend support for all, some or just one of them.

With respect to this particular issue, I've no idea about the
frequency of the problem, but having intermediaries rewrite HTTP
requests/responses is not uncommon.  How such an intermediary would
react to websocket traffic is entirely knowable, thus there could be a
concern that such an intermediary may allow websocket traffic to
commence and then interject some data at some point.

cheers





On 16 August 2010 15:22, Shelby Moore <[e-mail]> 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).
>>
>> cheers
>
> I am not stating that will happen or at any significant frequency, I am
> asking if it could be a problem? Why is the data currently limited to
> UTF8?
>
> Until evidence or expert experience is stated otherwise, my "Murphy's Law"
> (entropy) intuition is that if we inject clear (not encrypted) text data
> into HTTP channels, whose primary reason for existing is to be an
> orgy/feast of filtering (refering to the security discussion today between
> Willy and myself in this thread and the HTTP Compliance), that does not
> look and act like HTTP that those networks have seen, then we are
> prefering to risk a can-of-worms (indeterminacy). Although HTTP Upgrade is
> part of the specification (since 1.1?), am I correct to understand (from a
> comment made in this list's archives) that it has never been successfully
> deployed to any significant scale?
>
> And to the extent the above is a real issue, I had mentioned before in
> other thread that I would also be ask if there is a possibility that
> messages will silently fail to be delivered, so in that case TCP is not
> working as expected because it is not a failure-to-deliver to the network
> nodes, but rather a failure to forward data by the silent transparent
> proxy. So if so, then you need handshaking because the receiver doesn't
> know when data was sent. I had suggested that such handshaking could be
> accomplished (with least bandwidth wasted) in messages received and in
> keep-alive pings. But the more I think about it, if proxies might not
> forward data and we want to assume we have the behavior of normal TCP
> without proxies, then we will need to handshake on each sent message,
> which means latency advantage is destroyed! That is major point, if true.
> If proxies can eat the checksums (hashes), TCP efficiency is lost.
>
> This is why I am arguing in this thread for a clean break to a specific
> port+tunneling (aka WS/P+T), because it will give us a true TCP
> semantics+efficiency (after the tunnel succeeds) and the only issues not
> TCP recoverable will occur as a hard fail of the tunnel handshake, which
> is cacheable result (time cost) because can only occur once per tuple
> (client, server, DCHP lease, etc).
>
> Ian Hickson wrote more than once last year in this list's archives "443 is
> the interesting case", so I assume/deduce he had already worked through
> the above in his mind, and realized that WS/HTTP is really a can-of-worms
> if we can't get a hard fail at handshake for all non-compliant proxies. I
> think perhaps this is why he was so focused on minimizing "false
> positives" and why he made the comment that the failure of reverse proxies
> for proposal 76 was "a success".
>
> So that is why I say our good choices may be between WS/TLS and WS/P+T, so
> I proposed a fall back suite: WS/P+T -> WS/TLS -> Comet/BOSH (or leave
> this to the application to decide).
>
> I assume there are many details that need to be discussed (or re-iterated
> from prior discussion) to get a more objective understanding of this
> issue.  I am not satisfied or confident enough to say I have sufficient
> understanding of the facts, to argue that what I wrote about is anything
> other than a set of concerns and questions.
>
> I am hoping someone can collect and enumerate comparative facts with great
> organization skill.
>
>
>>
>>
>>
>> On 16 August 2010 11:12, Shelby Moore <[e-mail]> wrote:
>>>> Shelby,
>>>>
>>>> Maybe I've missed something in recent threads, but how is WS/HTTP more
>>>> vulnerable to data corruption?
>>>>
>>>> cheers
>>>
>>> Perhaps I misunderstood the issue.  Do some proxies monitor and filter
>>> the
>>> data, and may make mistakes because they think they are looking at HTTP,
>>> because they didn't properly recognize the Upgrade handshake?  And maybe
>>> other scenarios?  I really don't know.  I don't have enough experience
>>> with proxies.
>>>
>>> Also I read that certain data patterns (e.g. unencoded binary) can not
>>> traverse all proxies safely.  I realize perhaps we can avoid these known
>>> patterns, but doesn't that imply there might also be some unknown
>>> collisions?
>>>
>>>>
>>>>
>>>> On 16 August 2010 10:51, Shelby Moore <[e-mail]> wrote:
>>>>>> On 16 August 2010 10:24, Shelby Moore <[e-mail]> wrote:
>>>>>>>> On Sun, Aug 15, 2010 at 07:03:05PM -0400, Shelby Moore wrote:
>>>>>>> We must have that fallback no matter what we do.  All options
>>>>>>> forward
>>>>>>> have
>>>>>>> failure cases.
>>>>>>>
>>>>>>>> If I had the choice, I'd rather go for
>>>>>>>> WS/TLS with a quick fail to WS/HTTP.
>>>>>>>
>>>>>>>
>>>>>>> WS/HTTP can fail at random times after that quick fail, you still
>>>>>>> need
>>>>>>> Comet/BOSH.
>>>>>>
>>>>>> and Comet/BOSH can fail at random times.
>>>>>> All solutions need to handle the fact that the internet can fail
>>>>>> silently.
>>>>>>
>>>>>> I do not think it is possible to design a system that will always
>>>>>> fast
>>>>>> fail, other than an explicit declaration by a participant that a
>>>>>> protocol is not supported.   It is impossible to design a handshake,
>>>>>> whose success will guarantee the delivery of a subsequent websocket
>>>>>> message .
>>>>>>
>>>>>> The only real evidence of a protocol working is the protocol working.
>>>>>> The level of confidence in the protocol will be determined only by
>>>>>> mechanisms built into the protocol: messages, keep-alives, ping/pongs
>>>>>> and any extensions for acknowledgements etc.
>>>>>>
>>>>>> There is no silver bullet.
>>>>>
>>>>> Strong point, but won't the WS/port+tunnel (over TCP or equivalent)
>>>>> only
>>>>> fail-to-deliver and never corrupt, whereas WS/HTTP could corrupt the
>>>>> data
>>>>> (and will not support some data types at all, need encryption)?
>>>>>
>>>>> Also WS/HTTP is likely to fail more often during data transfer (after
>>>>> initial handshake) given reasonable robust networks.
>>>>>
>>>>> So they are not equivalent failure costs.
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>