0
\$\begingroup\$

Im doing a online game havingclient, js html5, and server, nodejs with websockets. I've read some blogs about websockets security, and its limitations, but no real implementation or example.

Could JWT tokens in the messages sent to the server, be a good option? Meaning when the clients connect to the server, it gets a token and passes it around on every message? And use wss instead of ws.

Thanks in advance!

\$\endgroup\$
0
\$\begingroup\$

Simple answer: No, it would not. Even if you would use Diffie Hellman key exchange on elliptic curves along with AES encryption, it would not.

Why: There can be the man in the middle attack, where someone will get in the middle of client and server, and read all data, and just forward them. Like this, you CAN bypass even Diffie Hellman key exchange.

That is way why SSL is here, since once you have SSL cert, then no one can really decrypt the communication, and your server is identified by the cert (so I can no create a fake server, as I would not have the certificate).

Also question: What do you want to secure? Make sure that other client does not send you a message as someone else? If so, then socket connection has a unique ID, therefore, you as the server can identify who sent you the message. (as far as I know)

\$\endgroup\$
  • \$\begingroup\$ "Use SSL" is what the question author means with "use wss instead of ws". \$\endgroup\$ – Philipp Mar 5 at 14:40
0
\$\begingroup\$

WSS means Websocket over TLS. So when you force the use of WSS instead of WS, you already solved most problems. Just make sure that

  1. The server certificate is valid and signed by a root CA
  2. The client authenticates with their username and password every time they initiated a new websocket connection (TLS on the web usually only authenticates the server, not the client).

The TLS protocol already provides you with encrypted channels which are encrypted with an unique encryption key for each connection. That means passing a token with each message is not required because the protocol itself already takes care of telling the connections apart. If implemented correctly it should not be possible for a man-in-the-middle attacker or eavesdropper to take over the connection of a different client.

However, TLS on the web usually only authenticates the server (client-sided certificates do exist, but are rarely used because they are difficult to set up for the end-user of the client). So after building the TLS connection you need to make sure that the client is who they pretend to be. The usual way to do that is by authenticating them via username&password.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.