5

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

Community
  • 1
  • 1
OCDev
  • 2,280
  • 3
  • 26
  • 37
  • 1
    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 Nov 21 '11 at 23:38
  • 1
    Why not simply use SSL? You can get valid/trusted certificates for free from companies such as [startcom/startssl](http://www.startssl.com). @BrianRoach: The *client* is in the corporate network, not the server. – ThiefMaster Nov 21 '11 at 23:39
  • 1
    you should read this : https://github.com/LearnBoost/socket.io/wiki/Socket.IO-and-firewall-software and this : https://github.com/LearnBoost/engine.io but i don't know when they will merge it. – malletjo Nov 21 '11 at 23:41
  • @racar: That's really good news. :) – OCDev Nov 22 '11 at 00:04
  • @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 Nov 22 '11 at 09:15
  • @EJP: To make a long story short, I hope most of us can agree that a better alternative (like convergence.io?) should be embraced and perfected in spite of the heavy political resistance that will come from the CAs that are printing money from the current system. http://www.networkworld.com/news/2011/101211-ssl-moxie-marlinspike-251882.html – OCDev Nov 22 '11 at 15:34
  • @FriendlyDev I might agree with the technical side but I'm not even interested in geopolitical rants. – user207421 Nov 22 '11 at 22:41
  • @EJP: I apologize for the misunderstanding. I didn't intend to say anything about geopolitics; rather politics that happen within the tech industry from CAs. Embracing progressive technologies is very important to developers like you and I and this community. – OCDev Nov 24 '11 at 00:24

3 Answers3

2

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.

Falsenames
  • 131
  • 2
2

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

Kornel
  • 97,764
  • 37
  • 219
  • 309
  • 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: https://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. – OCDev Nov 22 '11 at 18:52
  • 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](http://dev.w3.org/html5/eventsource/) which are HTTP-compatible and you can do fallback with XHR long polling. – Kornel Nov 22 '11 at 20:49
  • I looked into Server-Sent Events and became bitterly disappointed that IE is holding us back again: http://caniuse.com/eventsource – OCDev Nov 24 '11 at 00:34
  • 1
    I found a project that makes this work for IE6+ and I tested it in several browsers: https://github.com/Yaffle/EventSource – OCDev Nov 24 '11 at 01:27
1

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

alessioalex
  • 62,577
  • 16
  • 155
  • 122