A websocket server that is not hosted in port 80, will be invisible from Internet Browsers?
I cannot use port 80 (it's being used by IIS) neither 443 nor 8080.
Does websockets hosted on custom ports will have firewall issues?
The only way is to use IIS8 as to share the same port (80)?
(I'm using IIS7 with SuperWebSocket library)
Websockets that are accessed from browsers, should not be deployed in custom ports?
Thanks in advance.
To get to the heart of your question, I've had most success with realizing that my Web Server and Web Socket Server can both be on port 80, but different hosts ( origins ). As long as the Web Socket Server can handle CORS requests from your Web Page origin, it seems this is a way that avoids firewall problems and leads towards the architecture of having static content froma Web Server and dynamic from a WebSocket server.
So the story is:
serve page from web.server.com:80 (that's the origin)
in application space on that web page open a WebSocket to websocket.server.com:80/serviceName
(makes a cross-origin request that needs be be allowed by websocket.server.com, which might whitelist web.server.com)
happily serve dynamic content and static content separately.
Some more specific answers to some of your questions:
A WebSocket server that is not hosted in port 80, will be invisible from Internet Browsers?
No. Your application in the browser can open a WebSocket to other ports if that is desirable,
subject to CORS constraints. Oftentimes it is advantageous to keep the WebSockets on port 80, so that intermediaries and edge gateways don't have to change firewall rules.
I cannot use port 80 (it's being used by IIS) neither 443 nor 8080.
Does WebSockets hosted on custom ports will have firewall issues?
Most likely, unless you are in control of the firewall and can open up other ports.
If you have control over the firewall then there is no issue with running a websocket server on a custom port. You just need to open up the port to allow incoming traffic to that port.
The problem is not really firewalls per se but rather other types of filtering, proxying, load balancing, etc that happens before the traffic reaches your server. However, unless you have specific requirements that you didn't mention then there should be no issue with simply allowing traffic on that port.
If you WebSocket server is configured to limit connections to specific origins (CORS) then you will need to allow the origin to make connections. The origin is the address of the web server that will be serving up the web page that will make the WebSocket request. The default is usually either wide open or limited to the address of the websocket server itself.
According to here:
Warning: The server may listen on any port it chooses, but if it
chooses any port other than 80 or 443, it may have problems with
firewalls and/or proxies. Connections on port 443 tend to succeed more
often but of course, that requires a secure connection (TLS/SSL).
Also, note that most browsers (notably Firefox 8+) do not allow
connections to insecure WebSocket servers from secure pages.
Related
I have a web application running on a Bluehost server. I am trying to retrieve files hosted on a local server. On the local server, I have port forwarding and NodeJS listening on port 3000. I could do 80 as well, but from what I have read, that is not safe.
The issue I am running into is mainly the SSL cert for the local Node instance. The web application requires post requests to be made to https:// sources.
What are some best practice approaches to making this work? I have heard about installing Apache and running a ProxyPass to port 3000, but I am still concerned that the port 80 will have no SSL. Any help would be appreciated!!
First its worth noting that there are many approaches to hosting a web service.
Node can handle https connection, you should read the native https module documentation for how this works.
I tend to use Nginx (although apache is great and is a battle-tested solution) as a proxy server to node as, in general, I find it speeds up the process to get a product live. It also allows you to extract potential requirements from your node server, such as caching and SSL, so your node app can just focus on business requirements.
If you go for a proxy server, Nginx (and others), have modules that will handle SSL certificates. Lots of documentation online about how to set this up.
Something to keep in mind is that PORT 80 and 3000 are connection points for traffic. You will only be able to interact with the server on these ports if you bind and expose an application to them. If nothing is exposed to PORT 80, then connect attempts will just fail.
The best practices I tend to employ are:
No excuse not to use SSL nowadays, the standard is to expose https server on port 443.
If you choose to expose port 80, redirect all traffic to 443. This guarantees a secure connection.
I have a website behind cloudflare. I need to enable websockets over SSL without turning off cloudflare support. I have a PRO plan and hence won't get the new websocket support. I am using Nginx to proxy a SSL connection to a web socket running on a node server. Now, I read somewhere that cloudflare could work with approved ports would support websockets. Hence, I'm using 8443 for the Nginx port and another port for the node server. Using wscat it returns a 200 error.
$ wscat -c wss://xyz.com:8443
error: Error: unexpected server response (200)
I know that the websocket is expecting a 101 code. However, if I visit https://xyz.com:8443, I can see the page displayed by the node server telling me proxy is working. Also, once I turn off cloudflare support, the websocket starts working. Any clues to get this working. I know I can create a subdomain but I'd prefer running the websocket behind cloudflare.
If you're trying to access this through CloudFlare's network you'd need to explicitly have web sockets enabled on your domain before they will work -- regardless of the port. As in, even if the port can pass through our network, that won't automatically mean that web sockets will be enabled or accessible on your domain.
You can try contacting our support team to request an exception to see if they can enable it for your domain, but typically this is still only available at the business and enterprise levels.
Disclaimer: I work at CloudFlare.
From my understanding, WebSockets has been designed to traverse firewalls and proxies. Indeed, after an handshake between the client and the server, the communication protocol will change from HTTP to WS but it will still communicate on the port used to establish the handshake. (See websocket.org).
In other words, if a client can do an HTTP request on a given port, he will also be able to do WS on the same port.
However, according to XSockets configuration documentation, the port used for WS communications isn't the same as the HTTP port. Unlike a regular WS connection, a NAT on the firewall seems to be required to allow communication between the XSockets server and the client.
Is there a way to configure an XSockets server to re-use the HTTP port used for the handshake (port 80) without creating conflicts with the existing web applications hosted on the same web server (IIS)?
You are right. But, the application listening on the web port, should be able of understanding WebSocket protocol in order to do the handshake, and that is not the case of IIS < 8.
If you want to have your WebSocket running on the same port than your web application, you need IIS 8 (included in Windows >= 8 and >= 2012).
As far as I know XSocket allows you to use IIS8 as hosting environment: http://xsockets.net/docs/hosting#using-iis8
But if you have IIS < 8 , then it is not possible. It is not a XSocket limitation, it is a IIS limitation.
I have an application in mind which needs to communicate with an external (internet facing) "server".
The protocol itself is going to be really simple, and I was planning on doing everything over TCP/IP via Port 80 (or 8080) in order to hopefully pass seamlessly through firewalls. My "server" will be listening on port 80 (or 8080) for requests from my application. It will not actually be a web server (i.e. not expecting any HTTP traffic).
I have control over the network setup of the "server", but not the client environment. I will be coding both the client and server applications, so have control over those.
I have not really attempted any TCP/IP communication out of a LAN environment before, am I missing something obvious? I suppose my question is more like this: my client app is going to be run on all sorts of customer networks, of which I have no access to. Is this a sensible approach?
I would be most grateful for any hints/tips/gotchas.
For your use case, I think a better idea is to use http tunnel, because some firewalls will block non-HTTP traffic even if you are using port 80/8080.
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?)
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 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.
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