Re: [hybi] New port and Tunneling?

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

>> Give me one port that is supposed to remain open and I install a remote
>> proxy on it in order to bypass all mandatory filtering that makes the
>> web boring (but safe) to use from the internal network.
>
> You might as well just hack the browser, so then you need to close
> port 80 too.

AFAIR, Skype also uses port 80 (remember an issue of it interfering with
XAMPP), so I don't understand what will stop malware from using port 80,
even without hacking the browser?
















  Security (insurance) is a fallacy that
> results in abject poverty.  Rather bring the fence down and just reboot
> your computer when you click a bad link and your computer starts
> misbehaving.  Give the control back to the user.  End this slavery and
> restore freedom.
>
>>
>>> > Right now the success rate of tests appears lower
>>> > with HTTP than with TLS, but in my opinion, it will increase once the
>>> > protocol is ratified, because proxy vendors will simply add support
>>> for
>>> > it in their proxies.
>>> >
>>> > If you open a dedicated port, it's very interesting in order to
>>> reduce
>>> > the number of round trips, but you'll still miss a part of the
>>> population.
>>>
>>> See my point above, maybe the part is not larger than what will be
>>> missed
>>> with HTTP Upgrade, once the unknown soft fails are experience in the
>>> wild.
>>>  There will need to be fallback to Comet/BOSH no matter what we do.  So
>>> why not go for the simplest solution that gives us the most robust
>>> channel?
>>
>> The time to detect the failure can be huge.
>
> My other post earlier today I suggested to startup Comet/BOSH in parallel
> and use them while you are awaiting the timeout, so no delay at all.
>
>> Via a proxy it's generally
>> fast, you get an immediate rejection.
>
> I read in the archives of this list thatu can get a soft fail at any time
> with corrupted or delayed data.  Isn't there concern about what
> transparent proxies will do if look at the bi-directional data?  Okay
> maybe TLS is immediate rejection with no potential soft fail/false
> positive? But any way I think the startup delay is not an issue if you
> start up Comet/BOSH in parallel.
>
>> But via a blocked firewall, it
>> takes several seconds before you can decide that the port is closed.
>
> Agreed, but see my points above.
>
>>
>>> > Also, TLS as proposed by Adam looks very promising. But it still has
>>> the
>>> > inconvenient that it will never be blindly opened in many enterprises
>>> due
>>> > to the impossibility to analyse it.
>>>
>>> The tunneled specific port can be analyzed.
>>
>> yes that's a good point.
>
> Thank you.
>
>>
>>> > And it does not easily allow server
>>> > stickiness for a user connecting to the WS port of the HTTP server he
>>> was
>>> > on.
>>>
>>> I don't understand.
>>
>> On the server side, you generally don't have one single server, in fact
>> you have a farm of servers. Sometimes just 2, sometimes 10, or even 100.
>> For every requests that come in, a server is selected to process the
>> request. Stickiness is what ensures that a user will have all of its
>> session processed by the same server in the farm. It is very important,
>> otherwise each request would go to a different server and the server
>> context would be lost between clicks.
>>
>> When implementing WebSocket in web applications, you'll most likely
>> have to share contexts between the web server and the websocket server.
>> That means that most often you'll want them to run on the same server,
>> so you want to be able to associate a client's WebSocket connection
>> request with its HTTP counterpart, in order to direct him to the same
>> server. With an HTTP handshake, it's quite easy, just send the same
>> cookies. With a dedicated port, something has to be explicitly designed
>> in the new protocol to make this possible. TLS has the same issue.
>
>
> Because the webpage from served from the same server?
>
> Interesting point.
>
> Might be easy to solve with the tunneling algorithm I shared, because you
> could have each server emit a different packet signature to which the
> client sent the same signature replies.
>
>>
>>> > However, having TLS as a complement of HTTP would be very nice and it
>>> > could probably make sense to try it by default.
>>>
>>> How about TLS as a complement to specific port+tunnel?  Seems like a
>>> better combination.
>>>
>>> Hard fail -> TLS or Comet/BOSH (configurable choice, or let application
>>> layer implement)
>>
>> See above ;-)
>
> After replying to all your points, I repeat the question.
>
>>
>> Regards,
>> Willy
>>
>>
>>
>
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>
>