You can set up nginx to proxy a websocket connection between a browser and a server. Can nginx inspect the contents (perhaps using a technique similar to the way the auth_request module works for ordinary https urls) of the wss traffic. Why would this be necessary? For security purposes. Need to block bad requests on the web socket connection.
Note, in general there would be dozens of commands sent on any given connection.
Related
I have a chrome extension which uses an externel socket.io server to connect clients together.
During development I was able to connect to the server via http://localhost:2087 just fine, but right now I need socket.io to work over HTTPS so I can access it from a browser tab being server by HTTPS.
I don't want to deal with certificates, and want to keep the code on the socket.io server mostly the same, so I want to proxy the IP for the server via Cloudflare and establish SSL like that.
But I haven't been able to, the socket.io server uses no other webserver, but I can change it to use the native NodeJS http or https libraries.
But I haven't been able to access the socket.io server via the Cloudflare proxy. Clouflare returns 522 errors, which means a connection timeout.
Apparantly flexible SSL only works with with ports 443->80
Other ports are not supported...
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).
A web application i developed is sitting on a server that serves it under https, some of my js code requires to open a socket to another server (nodejs) who is currently not set for https. and thus browser wont allow it to run.
all i want is a simple way without getting involved with certificates just to initiate a https socket connection, i don't mind the lack of security,
just need app to run.
The certificates are not your problem. Your problem is CORS. You need to configure your server to answer with a header allows foreign-origin
res.header('Access-Control-Allow-Origin', 'example.com');
because in your case the technical difference between http (port 80) and https (443) is the port.
EDIT: ... I mean from the browsers point of view
I would like to add a some real time data updates using push to an existing CakePHP application. It seems to me that websockets are the best way to do so and from what I've read, the easiest way to start using websockets is with node.js. Now the issue I have is that my application server is very very limited portwise and there is virtually no way to change that.
I have apache currently running on *:80 and *:443 and sslh listening on port *:4433. Requests from the outside are sent to my server on :4433 and sslh takes care of handling ssh and https traffic, however on the inside, all my clients machines are using :443 directly. I could potentially open more ports for inside clients, but from outside, there is currently no way to do this. Most of my clients connect from the inside network, but more and more are using the application from outside too.
Note that port 80 is only used to redirect users entering http://example.com to https://example.com as all my services are encrypted. So if node.js was able to to send every http request to https and use port 80 for secure websockets, this would work too!
My question: Is it possible to run Apache and Websockets (probably in the form of Node.js) on the same port, and have either Node.js working as a proxy for Apache or Apache working as a proxy for Node.js?
In my setup, I have 2 layers of transparent proxies. When a client makes an SSL request, I wish to have the first proxy it meets simply forward the traffic to another one without attempting to do the handshake with the client.
The setup seems funny, but it is justified in my case - the 2nd proxy registers itself to the first one (through some other service) only occassionally. It tells the first: "I'm interested in some traffic that looks like___". In most cases, the 1st proxy simply does the work.
Can an httpProxy (in node-proxy) proxy SSL requests? Must I use an httpsProxy (which will then do the handshake with the client)?
You could do all of this with the existing httpsProxy if you wanted to. Unless you are wanting to use a non-Node proxy or proxy to a different server, I can't see what you would gain by having two.
Simply add the required the logging/signing logic to the existing httpsProxy.
Typically, I use https on the proxy to both restrict the number of open ports and to remove the need to do https on all of the Node servers running. You can also add Basic Auth using http-basic library too.
See my example code: https://github.com/TotallyInformation/node-proxy-https-example/blob/master/proxy.js
EDIT 2012-05-15: Hmm, after some thought, I wonder if you shouldn't be looking at something like stunnel to do what you want rather than Node?
(For reference, I've already made some of those points in my answer to your similar question on ServerFault.)
If you are after a MITM proxy (that is, a proxy that can look inside the SSL content by using its own certificates, which can work provided the clients are configured to trust them), it will hardly be fully transparent, since you will at least have to configure its clients to trust its certificates.
In addition, unless all your client use the server name indication extension, the proxy itself will be unable to determine reliably which host to issue its certificate for (something that a normal HTTPS proxy would have been able to know by looking at the CONNECT request issued by the client).
If you're not after a MITM proxy, then you might as well let the initial connection through via your router. If you want to record that traffic, your router might be able to log the encrypted packets.
Having your router catch the SSL/TLS packets to send them transparently to a proxy that will merely end up relaying that traffic untouched anyway to the target server doesn't make much sense. (By nature, the transparent proxy will imply the client isn't configured to know about it, so it won't even send its CONNECT method with which you could have had the requested host and port. Here, you'll really have nothing more than what the router can do.)
EDIT: Once again, you simply won't be able to use an HTTP proxy to analyse the content of the connection transparently. Even when using a normal proxy, an HTTPS connection is relayed straight through to the target server. The SSL/TLS connection itself is established between the original client and the target server. The point of using SSL/TLS is to protect this connection, and to make the client notice if something is trying to look inside the connection.
Plain HTTP transparent proxy servers work because (a) the traffic can be seen (in particular, the request line and the HTTP Host header are visible so that the proxy can know which request to make itself) and (b) the traffic can be altered transparently so that the initial client doesn't notice that the request wasn't direct and works as if it was.
Neither of these conditions are true with HTTPS. HTTPS connections that go through an HTTP proxy are simply tunnel, after explicit request from the client, which has sent a CONNECT command and was configured to make use of such a proxy.
To do something close to what you're after, you'd need an SSL/TLS server that accepts the SSL/TLS connection and deciphers it (perhaps something like STunnel) before your HTTP proxy. However, this won't be transparent, because it won't be able to generate the right certificates.