Is it a bad idea to use port 443 for Socket.IO?

Question

According to the following post, some networks only allow a connection to port 80 and 443: Socket IO fails to connect within corporate networks

Edit: For clarification, the issue is when the end user is using a browser at work behind a corporate firewall. My server firewall setup is under my control.

I've read about Nginx using proxy_pass to Socket.io listening on another port (which I've read about disadvantages) and also reverse proxy using nodejitsu/node-http-proxy to pass non-node traffic to Nginx (which has other disadvantages). I am interested in considering all possible options.

After much searching, I did not find any discussion about the possibility of socket.io listening to port 443, like this:

var io = require('socket.io').listen(443);

Where the client would connect like this:

var socket = io.connect('http://url:443/', {secure: false, port: '443'});

Aside from forfeiting the use of https on that server, are there any other drawbacks to this? (For example, do corporate networks block non-SSL communications over port 443?)

Most corporate networks are going to block all incoming connections except to production servers. And the ports that are allowed to those servers are going to be in use because ... that's why they're allowed. — Brian Roach
– Brian Roach, Commented Nov 21, 2011 at 23:38
Why not simply use SSL? You can get valid/trusted certificates for free from companies such as startcom/startssl. @BrianRoach: The client is in the corporate network, not the server. — ThiefMaster
– ThiefMaster, Commented Nov 21, 2011 at 23:39
you should read this : github.com/LearnBoost/socket.io/wiki/… and this : github.com/LearnBoost/engine.io but i don't know when they will merge it. — malletjo
– malletjo, Commented Nov 21, 2011 at 23:41
@FriendlyDev your opinions are entertaining but most of the e-business world disagrees with you. You might be surprised how little effect SSL has on network performance. I did some measurements a couple of years ago. — user207421
– user207421, Commented Nov 22, 2011 at 9:15

Kornel · Accepted Answer · 2011-11-25 14:55:47Z

Non-encrypted traffic on port 443 can work, but if you want compatibility with networks with paranoid and not-quite-competent security policies you should assume that somebody has "secured" themselves against it.

Regardless of silly firewalls you should use SSL-encrypted WebSockets, because WebSocket protocol is not compatible with HTTP (it's masquerading as such, but that's not enough) and will not work reliably with HTTP proxies.

For example O2 UK (and probably many other mobile ISPs) pipes all non-encrypted connections through their proxy to recompress images and censor websites. Their proxy breaks WebSocket connections and the only workaround for it is to use SSL (unless you're happy with Socket.IO falling back to jsonp polling...)

It looks like the long-polling aspect of socket.io is taking a more prominent role in the latest incarnation called engine.io released just 4 days ago: github.com/LearnBoost/engine.io (Instead of falling back to long-polling, it will fall forward to WebSockets. For my applications, long-polling may not be such a bad thing if it doesn't fall forward for some people.) I'd be interested in what you think about this.
If you're happy with long polling, i.e. you're only interested in quickly getting data from the server to the client, then try using Server-Sent Events which are HTTP-compatible and you can do fallback with XHR long polling.
I looked into Server-Sent Events and became bitterly disappointed that IE is holding us back again: caniuse.com/eventsource
I found a project that makes this work for IE6+ and I tested it in several browsers: github.com/Yaffle/EventSource

Falsenames · Accepted Answer · 2011-11-21 23:37:10Z

It really depends on what type of firewall is set up. If the ports are just blocked, then pretty much anything can run on ports 80 and 443. I have used this myself to get an ssh session to my home computer over port 80 when stuck behind a firewall at work.

There are a few firewalls that have more advanced filtering options, however. These can filter out traffic based on protocols in addition to the regular port filtering. I have even run up against one firewall in front of a server that would stop https traffic through an ssh tunnel somehow. These advanced filtering techniques are the rare exception by far, so you should be fine with just listening on 443 for most instances.

alessioalex · Accepted Answer · 2011-11-22 08:41:12Z

I think you should read the whole wiki article about Socket.IO and blocked ports (by antiviruses, firewalls etc):

https://github.com/LearnBoost/socket.io/wiki/Socket.IO-and-firewall-software

Collectives™ on Stack Overflow

Is it a bad idea to use port 443 for Socket.IO?

3 Answers 3

4 Comments

Comments

1 Comment

Linked

Hot Network Questions