Node.js & Socket.io: self-signed certificates for secure network connectivity

Question

I surf the internet looking for a direct answer, but most solutions include using Express and serving HTTP content for secure connections. I'm more interested in secure web socket connection ( wss ) for Node.js and socket.io

I do not use Node.js for HTTP requests. I use the socket.io module, which works with Node.js to deliver real-time messages to my applications. I am using node to connect to a web socket.

I will explain what my setting is. I use Django as my HTTP server. Users make a Django request, Django sends the contents of this request to Redis, Node.js listens to one of the Redis channels, processes the content and sends a message to the appropriate recipient.

Pretty simple and straightforward. Everything is working fine. But I'm afraid that connecting to a webcam with Node.js is unsafe. When Node.js sends a message to the recipient, I don’t want anyone to track between them and intercept the message. I would like to make sure that my users feel secure and trust the service I created for them.

I looked at self-signed certificates and certificates from CA. Both provide the same level of security. Since I use Node.js for socket.io and do not serve HTTP content, the self-signed certificate will work absolutely fine (the service I created for mobile devices, not browsers!)

Below is my implementation of socket.io:

var io = require('socket.io').listen(8000); var redis = require('socket.io/node_modules/redis') var redisChannelConnection = redis.createClient(6000, "12.345.678.9"); var redisServer = redis.createClient(6000, "23.456.789.1"); // Subscribe to Redis Channel redisChannelConnection.subscribe('messages'); io.sockets.on('connection', function (socket) { socket.emit('message', 'Hello World'); } 

I just wrote a simple join function. It works like a normal websocket connection. But I would like to make this a secure network connection. . How much do I do this?

Thank you for your help.

Answer 1

First you need to create an HTTPS server in node (for which you need a certificate):

http://nodejs.org/api/https.html
How to create an https server in Node.js?

Then you should use this server to run Socket.io.

 var io = require('socket.io').listen(myHTTPSserver); 

This should be all that is needed.

There are two ways to protect your connection from man-in-the-middle attacks:

• Using a signed certificate and verification by the client of this signature. The internet is filled with explanations of why this is actually a pretty bad decision.
• Make sure the client refuses to connect to anything other than your certificate. Any decent SSL / TLS library will allow you to specify a certificate that should be used for outgoing connections, if the key at the end of the server does not match this certificate, the connection is interrupted. This does everything that a signing system should do, but does not rely on the fact that every CA certificate in the world is honest or any other flaw in the CA system.

Your combination of Django / Node.js sounds rather strange, is it correctly understood that clients make requests on one channel and receive a response on another channel?

While this may be technically good, it sounds like a recipe for creating strange vulnerabilities. If you should use both options, consider making a node proxy for Django content and node to handle all authentication.

In any case, I seriously doubt that encrypting only one of the two channels is enough, as soon as the hacker posted one channel, most likely there will be many options for escalation.

Answer 2

I looked at self-signed certificates and certificates from CA. Both provide the same level of security.

No, they do not. SSL security has nothing to do with HTTPS (for example, HTTP inside SSL) or wss (for example, a socket inside an HTTP tunnel inside SSL). SSL provides end-to-end encryption, but this end-to-end can only be guaranteed if you can identify the other end. What are certificates for? A certificate signed by a trusted CA means that some CA has reviewed the certificate data and made sure that the data in the certificate matches the owner. But the self-signed certificate simply says that the owner himself thinks that everything is in order, but no one trusted, looked at him. For this reason, self-signed certificates are not trusted by default, and each user must explicitly trust the certificate (I hope after somehow confirming the owner).

Answer 3

Firstly, I completely agree with another answer that self-signed certificates are not so secure, but at the same time about it ... What you want to do is "https" instead of "http" and pass your certificate parameters to createServer to create your HTTPS application. The options are basically the same as TLS here . Then, when you call to listen on socket.io, you will listen via HTTPS instead of HTTP.

Now back to the real problem, which is a misunderstanding of the purpose of the CA. I agree that even a self-signed certificate will encrypt the contents, but the self-signed certificate is not verified by anyone else, which means that someone else can create their own self-signed certificate, which is equally reliable. An attacker in a cafe can create a WiFi network that seems legal. Controlling this network, he can stand in the middle of all requests. All he needs to do is create his own self-signed certificate for your domain name, and he will not only be able to decrypt, but also modify all the requests. This applies not only to browsers, but also to mobile applications for Android, iPhone or everything else. The certification body has a place for the operating system to determine which root certificates trust the issuance of certificates. Since an attacker cannot register a certificate for your domain name with a trusted certificate authority, any certificate verified in this way ensures that the computer from the other end is actually the intended computer. Self-signed certificates are developing well, but using them in production allows you to transfer any data sent through your application in order to replace your server, disclose information and falsify messages.