Re: [hybi] New port and Tunneling?

[Willy Tarreau <[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.
In your opinion, why do Comet/BOSH work over HTTP ? Precisely because
they can reach almost 100% of the visitors. 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. 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.

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. And it does not easily allow server
stickiness for a user connecting to the WS port of the HTTP server he was
on.

However, having TLS as a complement of HTTP would be very nice and it
could probably make sense to try it by default.

Regards,
Willy