Re: [hybi] New port and Tunneling?

[Willy Tarreau <[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, firewalls don't block explicit
things, they're just open for explicit things. 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 ;-)

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

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

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

> > 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. Via a proxy it's generally
fast, you get an immediate rejection. But via a blocked firewall, it
takes several seconds before you can decide that the port is closed.

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

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

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

Regards,
Willy