Re: [hybi] New port and Tunneling?

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

> On Sun, Aug 15, 2010 at 07:03:05PM -0400, Shelby Moore wrote:
>> >> 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.
>
> exact.
>
>> 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.
>
> Once again, simply because it requires opening an uncontrolled port
> to you-dont-know-where.

I did not imply that the enterprise must open it, it can allow it to fail
and WebSocket can fall back to the another option, e.g. Comet/BOSH and
HTTP Upgrade on port 80 (since TLS won't work on Enterprise).

My point is that at least port+tunnel will work on the more widespread use
cases outside the enterprise, probably as often than HTTP Upgrade on port
80 will and with better hard fail and better performance (less quirks
after tunnel succeeds).

> Maybe it will succeed once it has lived 5 years
> and vendors start building devices capable of following the framing and
> kicking out unauthorized users. But in the mean time it won't get adopted
> in enterprises (at least), and probably not at mobile phone operators that
> don't want you to connect home via openvpn or SSH.

Afaik, we don't have that problem with USB broadband mobile convergence
here in Philippines.  They even open the Skype ports, probably because
people are not anal about it, they just want to innovate and do more with
the internet (while they blow by us in terms of usage and market
innovation).


>
>> > 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?
>
> yes, that's what I'm saying from the beginning.

Lets think outside the Enterprise please, where the big prize is. 
Enterprise is going to always be a least common denominator, e.g.
Comet/BOSH perhaps.  Enterprise will die any way (the future is already
moving away from that slavery over here).

>
>> 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).
>
> The problem if we ignore the enterprise market is that site implementors
> will have to continue to use Comet/BOSH just for this minority of users.
> So why would they implement two solutions when the existing one is still
> necesarry and already enough for the job ?


Exactly.  We better focus on the useful use cases.  That is what I am been
trying to say from my earlier posts.  We need to focus on where this
advance can actually advance and be adopted in wide scale.  Focus, focus,
focus.   80/20 rule.

But I am not sure my characterization of the market is accurate.  Please
correct me if you any one knows for sure.

>
>> > 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.
>
> Here it's different, it's keeping it for a very few years, the time needed
> for buggy intermediaries to get fixed in next version.
> There's a big
> difference between fixing a device which is not HTTP-compliant to make
> it compliant, and implementing support for a fresh new protocol.

And the difference favors the latter?  The former may mean years of
gradually surfacing soft fail complexity hiccups, or soft TLS issues.  The
former is either hard success or a hard fail and deterministic downgrade
to status quo.

By "soft", I mean the failures will come in the market and at unexpected
junctures, perhaps even at random times and situations. Am I mistaken?

>
>> >> 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.
>
> Fine if you use your PC for games and don't mind experiencing the same
> day every day. But when you use it for work, you certainly appreciate
> finding your last files when you boot it :-)


Use an exception drive or folder.

When I installed Baseline Shield, I turned off my firewall and have never
looked back.  Works like a charm.  I can't understand why there isn't a
massive exodus from the current insanity.  Either I am missing something? 
Or others just haven't thought of it?


>> > 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.
>
> No, because when the browser can only get out via the proxy, it does not
> have access to port 80 itself, otherwise it would be pointless to install
> filtering devices !

Okay I understand your point now which is that HTTP is filtered and
another port is not unless the proxy understands the spec.  But SSL is not
filterable because the proxy can't see the unencrypted data, so block all
secure ecommerce and personal privacy?

I think it is pointless to install filtering devices if you depend on them
for security.  Kills anonymity, privacy, thus free speech.  And especially
critical in this epoch ahead of us.

Also I expect that HTTP over port 80 will become so well attacked (from
the application state machines) that will have to close port 80
eventually.

It is the way insurance always ends, complete failure.  Every time in
history.

Rather just give the user a disk image reset button with an exception file
folder.  This is decentralized fencing and thus is free market.  The
centralized fence with no leaks eventually become a solid wall that
nothing can pass through.  Proxies should only be used to add capability,
not restrict it.  The entire model is wrong and we are going to suffer
horribly for it.


>
> In the past, I used to telnet over mandatory HTTP proxies using POST
> requests, but controls have improved and the data does not flow back now
> until the request message is sent and the response analysed.
>
>> 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.
>
> Two competing implementations to maintain for the site owner.


They are going to have to do it any way, no matter what we do.


>
>> > 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.
>
> Yes, with transparent proxies. Explicit proxies have the cleanest method
> (CONNECT). Some of them will still block due to port 80 not being allowed
> with CONNECT though, which is where Adam's proposal may improve things a
> bit. But this is just a matter of configuration. The desire to accept or
> block such requests will be equal whatever the port, in both cases it's
> uncontrolled bidirectional tunnel.


Thanks for confirming and qualifying.

>
>> 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.
>
> Also it would be nice to avoid starting the two in parallel for every
> connection.

You only need to test failure once per client and server pair, with the
hard fail of port+tunnel.  Whereas with the confirmed soft fail issues
over HTTP ports, you will never know if you have confirmed success that
you can cache.

> It will basically double the traffic on some sites, which
> is not nice at all, resulting in them not implementing WS at all in the
> end.

Not all sites with have such a profile.  And ditto the point above that we
only need to succeed or fail once for port+tunnel.

Offer a configuration option to only start one type, and let the market
decide?


> We must keep in mind that the goal of the spec is to propose
> something that people want to deploy, otherwise it's a failure.

How does this not support my logic so far?


>
>> > 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?
>
> You want every part of your application to be able to access its context.
> If the context is shared, any host can access it. If it's local (more
> scalable), then only local servers may access it. So you have to ensure
> that all requests from a given user as well as its WS connections can go
> to the same server.

See below...

>
>> 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.
>
> yes, possibly, though it still requires developping support for a new
> protocol in existing components, while with HTTP at least there's nothing
> to do (except sometimes fix a few ones).

"nothing to do" is not the way I would characterize the mess ahead with
soft fail in HTTP.  Consider the actual cost in the market place.

>
>> >> > 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.
>
> As I said, none of TLS and your specific port addresses the stickiness
> requirements.

I thought I did above?

> WS/TLS + Comet/BOSH still requires support for two different
> protocols on the server side.

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.

What advantages and disadvantages does WS/TLS offer over port+tunnel? 
Ditto WS/HTTP?

Maybe someone can make an ascii table summary.


>
> Regards,
> Willy
>
>
>