I was trying to sniff HTTP packets though wireshark on my localhost, when i tried working on a web2py instance at my localhost no http connections found. While digging deeper into it i found it is not creating `any connections in the application layer. well then how does it communicate with browsers without http? (I have heard of web2py as a very secure framework, now this thing is creating more curiosity in me)
Are you sure it's not an HTTP connection on port 8000 (which is the IANA registered port for irdmi)? If you use wireshark, you can choose to decode as HTTP when the port isn't the standard port for the protocol.
Related
For my academic project, I am trying to achieve this.
A web server node JS application listening on port 3000.
So If you curl http://localhost:3000 you will get Hello World!. ( A simple web page.
Now I am running above webserver in my local machine. And my modem is behind NAT. Suppose If I port forward in the modem to myip:3000 then it is open to the world. But here is the biggest thing I am stuck - I don't want to use the modem for port forwarding, instead, I will use third party server for UDP Punch Hole.
Now my requirement is anyone from net should able to access my webserver at curl http://third-party-server-ip:3000.
What I am trying is to write another client - which opens a connection to the third party server. Say it did a hole punching at port 41234. That port is open. The third-party host can send something to that port.
Now anyone in the internet initiate this command curl http://third-party-ip:3000 to the third party host. So the third party returns the myip:udpPunchHolePort i.e., myip:41234.
anyone will again curl to myip:41234 it will be received by the node js UDP punch app, so it will redirect to localhost:3000. Finally, the anyone will receive the response from localhost:3000.
My two questions -
Is there any better way than the one I proposed here?
Is there any well-known node-js lib for this kind of stuff, I see,
I can use UDP punch hole. Or I am thinking to write a Lib to do this in general - does this sounds like re-inventing the wheel?
Note -
In this academic project, we are trying to learn how to make any local application open to the world without port forwarding in the modem.
We read on skype protocol analysis, that is also our inspiration.
No, that won't work.
HTTP runs over TCP, not UDP. Punching a UDP hole doesn't do you any good -- any TCP connection to the backend HTTP server will still fail.
HTTP redirects are not magic. If a user cannot access a specific host:port, redirecting them to a URL on that host:port will just make their browser time out when it requests that URL.
You cannot send a response from a different host:port from what the browser requested, because there is no TCP connection established with that endpoint.
I'm making an app using node.js' express framework which serves both html content over http and uses websockets for a chat feature. I'm wondering how I can accomplish both at the same time. My idea is to use a different port for websocket connections (so http requests would come to port 3000 and websockets would connect on port 3001) but I don't know if that's a good solution. I'm especially worried about deployment to something like heroku and if I can specify different ports for my app.
I'm wondering how I can accomplish both at the same time.
The webSocket protocol is specially designed so it can run on the same port as your regular web server requests. So, you don't need a separate port in order to have both a web server and chat running using webSockets.
This works because a webSocket connection is always initiated with an http request that sets a few special headers. The receiving web server can then detect those special headers and know that this incoming http request is actually a request to initiate a webSocket connection. With a particular response, the client and server then agree to "upgrade" the connection and switch to the webSocket protocol. From that point on, that particular TCP connection uses the webSocket protocol.
Meanwhile any incoming http request that does not have the special webSocket headers on it is treated by your web server as just a regular http request. In this way, the same server and the same port can be used for both webSocket connections and regular http requests. No second port is needed.
Another advantage of this scheme is that the client can avoid the cross-origin issues that it would run into if it was trying to use a different port than the web page it was loaded from.
I'm especially worried about deployment to something like heroku and
if I can specify different ports for my app.
If you were to actually use two ports, then you would need to create two separate servers, one listening on each port since a given server can only listen on one port. In node.js, the two servers could both be in the same node.js app (making it easier to share data between them) or you could put them in completely separate node.js processes (your choice).
And, if you used multiple ports, you'd also have to support CORS so that the browser would be allowed to connect to the separate port (to avoid same-origin restrictions).
I'm working on a project where some clients (embedded linux systems) needs to connect to a main server using so far at least two protocols: HTTPS and SSH. One of the requirement is that only one flow is allowed from every client to the server, so I've to found a way to make the two services works on the same port.
One solution that I was thinking about is to use the iptables markers: on the client side mark the packets for SSH with 0x1, the packets for HTTPS with 0x2 and then on the server side, based on the marker, redirect the packets to the right service listening on the local interface. Is it an acceptable solution? Are the markers kept by the network routers or is only something working locally on the same machine for iptables?
And anyway, if you can advice about a different solution, of course it's welcome!
More for other users finding this question in the future:
https://github.com/yrutschle/sslh has what you might need. I haven't used it (yet) but planning on it.
From the Github site:
sslh -- A ssl/ssh multiplexer
sslh accepts connections on specified ports, and forwards them further based on tests performed on the first data packet sent by the remote client.
Probes for HTTP, SSL, SSH, OpenVPN, tinc, XMPP are implemented, and any other protocol that can be tested using a regular expression, can be recognised. A typical use case is to allow serving several services on port 443 (e.g. to connect to SSH from inside a corporate firewall, which almost never block port 443) while still serving HTTPS on that port.
Hence sslh acts as a protocol demultiplexer, or a switchboard. Its name comes from its original function to serve SSH and HTTPS on the same port.
I have ExspressJS app run with Socket.io, due to firewall issues with higher port for SIO i want to switch that both will work on port 80.
Found this small article and on my dev machine it's look working good.
My question is, is it really goo to do that? is it a good practice? if not why?
Please advise.
It makes absolute sense to run socket.io and your web server on the same port.
The webSocket protocol (which socket.io is based on) is specifically designed for this to be the primary way that socket.io is used for a bunch of reasons including same-origin permissions and client and server firewall routing of port 80.
In case you didn't realize it, every socket.io connection starts with an HTTP request to a specific route and then once the initial handshake between client and server has been confirmed, then the protocol is "upgraded" from HTTP to webSocket. Because all socket.io connections connect in on a very specific route, all other HTTP connections can easily be separated out and be treated by your web server as regular web requests.
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