Will html5 websockets be crippled by firewalls?

Question

I'm extremely excited about html5's websockets spec but I have a concern.

These days everyone is operating off of some network, with routers (wired/wireless) that have built in firewalls, windows has a built in firewall too.

With that in mind when the server attempts to connect back to the browser that started the websocket handshake will it fail for the vast majority of users? (most people have no idea how to set up port forwarding on their routers)

Or is my thinking incorrect and it will go through fine?

Solution 1

I'm not an expert (so please check to confirm) but I believe there will be an UPGRADE mechanism where a regular HTTP connection can be made, then upgraded to a WebSocket, so no existing firewall rules interfere unless they are doing aggressive application level packet inspection. Connections are still initiated by the browser.

Solution 2

HTML 5 WebSockets don't require port forwarding. Connections continue to be established from the client, but the client and server asymmetry disappears once the connection is established. WebSockets also punch through proxies by using the same CONNECT mechanism that HTTPS uses today.

Solution 3

Since firewalls typically simply enforce the rules for inbound traffic rejection and outbound traffic routing (usually through the proxy server), there usually are no specific WebSocket traffic-related firewall concerns.

Proxy servers (and to some extent, certain load balancing routers as well) are a different matter though (See Why don't current websocket client implementations support proxies?)

Comments

[teepark]

I believe you're right, the whole protocol is effectively an extension of HTTP so all the traffic goes over port 80

[Brian Dilley]

Any firewall that does statefull packet inspection will drop WebSocket traffic. After the upgrade - it's not HTTP anymore.

[andrewjsaid]

it is actually not HTTP. it is designed to fool firewalls to seem LIKE HTTP.

[joshperry]

@Brian Statefull firewalls only verify that a packet correlates to an existing, unclosed, connection. It tracks the state of the connection (opening, open, closing, closed) hence the name. When it detects a packet is part of an already open, authorized connection, it can short circuit all of the other rule checks and let the packet through. What you're thinking of is a layer 7 filter. These are much less common, and much more expensive than normal layer 3 statefull firewalls found by default in most OSs.

[JohnMudd]

FWIW, I'm currently unable to connect to websocket server from a customer network. The connection attempt hangs indefinitely. So far I found they are using WatchGuard.com. I'm allowed to access HTTP on my websocket host but websocket connection hangs. WG site lists bug: "Connections with WebSocket protocol (RFC6455) fail through HTTP Proxy and HTTPS Proxy with Content Inspection". Status is "open".

[Pacerier]

@BrianDilley, So they drop HTTPS packets too?

[Pacerier]

@JohnMudd, What happens with HTTPS for such firewalls?