Re: [hybi] workability (or otherwise) of HTTP upgrade

from a proxy / firewall vendor perspective, overloading yet more 
functionality over port 80 CONNECT is something that will simply cause 
us more work, and require us to put more resources into dealing with the 
sort of requests made by CONNECT.

It's bad enough already having malware use CONNECT, so you have to lock 
it down.

Trying to distinguish legitimate use from undesired use gets more 
difficult the more you put over this.

It means you pretty much need to put a firewall and protocol sniffing on 
top of your tunneled connections.

So, where does this lead?  Everyone starts using port 80 for everything, 
and in the end port 80 will be where TCP is now.  Highly restricted.

Except for the additional overhead and complexity = bugs, worse 
performance and security problems.

Maybe we need to stop and think about why the other ports are blocked, 
which compels us to try and circumvent company policy by looking for 
back-door ways to get connectivity.

Mark's comments about an arms-race are spot on.

Whilst you may get good odds of a successful connection now, wait a few 
years when people start locking CONNECT down and it will likely be no 
better than TCP on a different port is now.  Except coaching customers 
to lock down CONNECT is a PITN.

Cheers

Adrien


On 7/12/2010 7:10 p.m., Willy Tarreau wrote:
> On Tue, Dec 07, 2010 at 01:13:28PM +1100, Mark Nottingham wrote:
>> On 07/12/2010, at 12:30 PM, Maciej Stachowiak wrote:
>>
>>> On Dec 6, 2010, at 4:53 PM, Mark Nottingham wrote:
>>>
>>>> I don't think that's the relevant aspect here. "Another port" could be port 80 or port 443 (nasty, and you wouldn't make it the default, but I think you see where I'm going).
>>>>
>>>> The question is why it's necessary to run both HTTP and WebSockets traffic over the *same* port simultaneously -- something that AFAICT is taken as axiomatic, and I'm really wondering why.
>>> Web developers will likely want to operate both a WebSocket service and an HTTP service on the same server, since WebSocket services are likely to be most useful in combination with a Web application that makes use of them. At the same time, they will want their WebSocket traffic to go through firewalls properly. It would be a significant burden if a WebSocket service required a separate domain name, physical or virtual server, and possibly SSL cert.
>>>
>>> Thus desire to have a single piece of server software that can dispatch connects to HTTP applications or Web applications as appropriate.
>> You don't need a different domain name, hardware, OS instance or certificate to listen to a different port, and if you have a wildcard SSL cert, you can use the same cert for the same port number on two different hosts.
> In my opinion the problem is not here, but the adoption rate depending
> on the port. Many organisations implement URL filtering on port 80,
> white-list based filtering on 443 and nothing else around. If you want
> to deploy a site which quickly gets a lot of traffic, port 80 clearly
> is the most suited, which is even more true considering that long polling
> mechanisms already work over that port.
>
> Also, being able to switch from HTTP to WS over a same socket for some
> services can save one round trip, but that's marginal in most situations,
> except from mobile phones.
>
> Regards,
> Willy
>
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Tuesday, 7 December 2010 06:43:27 UTC