Re: [hybi] New port and Tunneling?

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

> On Sun, Aug 15, 2010 at 06:01:48PM -0400, Shelby Moore wrote:
>> > In many (I mean *many*)
>> > enterprises, here's what you have as options to access the outside :
>> >   - port 80 via a proxy/cache/anti-virus/url-filtering
>> >   - port 443 on a small hand-selected list of sites
>> >   - nothing else
>> >
>> > I've heard it's basically the same with mobile gateways at most
>> operators.
>> >
>> > And given the number of malware on the net, the trend is certainly not
>> > going backwards. Thus, port 80 with HTTP has a major advantage over
>> the
>> > other alternatives.
>>
>> Did you look at the links I provided?
>
> just quickly.
>
>> AFAIU, the firewall/NAT would have
>> to block traceroute in order to stop this tunneling.
>
> Well, mind you that in many enterprises,

You also wrote that TLS is likely to fail in many enterprises also.

And HTTP Upgrade has soft fail indeterminism "root canal" risk.  I
understand from archives that we really won't know until we put into the
wild, with all the stacks of transparent proxies mucking around in the
bi-directional packets. You fix that by going to TLS, but you just wrote
that TLS is also going to be blocked by many enterprises.

So I don't yet see that valid argument against port+tunnel for enterprises.

> firewalls don't block explicit
> things, they're just open for explicit things.

The links I provided state that firewalls are only typically closed for
incoming, not outgoing and incoming replies to outgoing. Maybe you are
thinking of mostly in the enterprise? The enterprise is much smaller use
case than home/SOHO/asian netcafe, and we don't have a good solution for
the enterprise other than to fall back to Comet/BOSH (standard HTTP to
avoid potential soft fail/false positive proxy hell).

> In almost all places I've
> been, there is zero communication between the inside and the outside that
> does not pass via proxies. So if the proxy refuses your request, you can't
> pass. Then you can always try to fool the proxy using request smuggling,
> but it does not always work ;-)


Fall back to Comet/BOSH, which we are going to have to for HTTP Upgrade on
port 80 or TLS on port 443 also.


>
>> I suppose the
>> firewall could block the specific port (knowing that traceroute doesn't
>> normally run on that port)?  But why would the firewall want to
>> retroactively block our specific port,
>
> It's just that it would never have been explicitly opened.

Ditto above.


>> when malware wouldn't be able to abuse that port+tunneling and more than
>> malware could abuse port 80,
>
> Right now malware already uses many evasion techniques to send information
> outside and download updates.


The solution to that is run Deepfreeze, Rollback, Baseline Shield, or any
other means of restoring your computer to virgin state on each reboot.  I
am really surprised this isn't built into every operating system by
default.  If you go back to the security debate we just terminated in the
other thread, the use of firewalls is in direct defiance of the laws of
nature and computer science.

What will end up doing is killing all innovation.  It really sucks, and
especially at a time when we need to be expanding P2P in order to create
robust decentralized economic responses to the global socialism that is
going to render all of us penniless.  But P2P can't go any where because
put the security at the perimeter instead of at the ends.  Insane (not
you, the situation).

>
>> especially if there was already a rapid adoption of popular applications
>> that relied on the port staying open?
>
> 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.  You see it is insane.  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
>
>
>