Re: [hybi] New port and Tunneling?

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

> On Sun, Aug 15, 2010 at 04:48:35PM -0400, Shelby Moore wrote:
>> I googled this discussion list archive and did not find much on this.
>>
>> Seems the great likelihood of messy soft failure and other a priori
>> unquantifiable complexity with reusing the port 80 or 443+TLS due to the
>> HTTP legacy on the network and/or complexity issues with HTTP Upgrade or
>> non-mainstream use of TLS.
>>
>> Seems what we really need is a hard fail, so we can dynamically and
>> gracefully downgrade to long polling solutions (Comet/BOSH...).
>> K.I.S.S.
>>
>> We are going to have to downgrade whether due to proxy soft failure or
>> new
>> port tunnel failure, so why chose the higher complexity "root canal"
>> route?
>>
>> Am I missing something or is the K.I.S.S.  way to get a hard fail is
>> tunnel over a new port?  Then we can get P2P WebSockets too (wow)!
>>
>> http://samy.pl/pwnat/
>> http://mackys.livejournal.com/896428.html
>>
>> FAQ at the above link seems to be pretty simple and deterministic in
>> terms
>> of failure detection.
>>
>> The man-in-middle vulnerability and the beneficial features of HTTP
>> (e.g.
>> URL redirection, virtual hosting,...) could still be obtained by
>> handshaking orthogonally with standard HTTP GET.
>>
>> Educate me please.  Certainly the solution can't be this simple correct?
>> Why?
>
> The specific port was discussed too. But it does not solve everything.

But no solution will solve everything.

Rather I am arguing that a hard fail at firewall tunnel attempt, is
superior to soft fail at unknown times in the corruption/delay of data by
the proxies or other complexity of trying to shoehorn a bi-directional
channel into a stack that isn't designed for it.

Once the specific port tunnel succeeds, we get rid of all the other
problems.  If it fails, we know it, and can gracefully degrade to the 100%
reachable Comet/BOSH options.

> In your opinion, why do Comet/BOSH work over HTTP ? Precisely because
> they can reach almost 100% of the visitors.

Agreed.

> 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?  AFAIU, the firewall/NAT would have
to block traceroute in order to stop this tunneling.  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, when malware wouldn't be able to
abuse that port+tunneling and more than malware could abuse port 80,
especially if there was already a rapid adoption of popular applications
that relied on the port staying open?


> 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?

>
> 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.

> 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.

>
> 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)

>
> Regards,
> Willy
>
>
>