Dear Faye users,
I would like to share that I am having good results using STunnel (
http://www.stunnel.org/) to do the SSL heavy lifting for Node.js/Faye. It works for both long-polling and WebSocket transport. Also seems to have good performance, because it does stuff like SSL session caching.
As you all might know, current SSL support in Node.js is far from finished. I know people hard working hard on this subject, but I needed something working today.
You will notice that the connection to the Faye server will only last for about ten seconds ... then the client doesn't receive any more messages from the server.
My current setup looks something like this: browser --[SSL]--> STunnel:443 --[NON-SSL] --> node:5000
There is also one problem I would like to share. When using a reverse proxy to do SSL and maybe some load balancing (you could in theory use HAProxy, NginX or maybe Mongrel2, but in practice STunnel is one of the few to support both WebSocket and SSL), there is a minor problem with the WebSocket handshake.
Let's say a WebSocket client connects to 'wss://
chat.domain.com'. This will establish a secure connection to the SSL-proxy. Now the SSL-proxy will forward this connection in a non-secure way to the Node server. This causes request.socket.secure to return false ... so the url returned to the client is 'ws://
chat.domain.com', which will cause a handshake mismatch in the browser.
As far as I know, there is no way to tell if the request has been forwarded by STunnel, except for the origin being 'null'. So I resorted to hardcoding faye-node.js to always return a 'wss:' url. Of course this is no real solution.
One option would be to write a patch for STunnel to add an 'X-FORWARDED-PROTO' header, which Faye can use to check if it should return a 'wss:' or 'ws:' url ...
Any thoughts?
Bests,
Matthijs