CODEWITHSUNDEEP
securitysslwebsocket
Metalskin
Metalskin

Reputation: 4268

Does it make sense to use WSS for authentication and then use WS for data?

I'm doing some work with websockets and need to address security. From what I have read it is apparent that SSL is the best approach in my circumstances so WSS is the way to go (this isn't the question, just statement of fact).

The server may stream a large amount of data to clients. The data isn't private or sensitive so I am not worried about anyone sniffing the data. My main concern is that the WS connection is validated as receiving commands at the server could be harmful and destructive. The client must be trusted.

The server will be an embedded device with limited processing power. So my view is that the data can be transmitted in the clear via WS.

So my approach is for the client to wss to connect to the server, authenticate and request a session key. The client then will disconnect from the wss connection and then connect via ws to the server, passing the session key received from the previous wss connection. The server will only accept a ws connection if the connection immediately passes a valid session key (with an appropriate expiry time on the session key). One connection attempt only via ws will be allowed per client, with a reset on a successful wss connection.

So my question is if this approach is reasonable or if my approach will have some serious vulnerabilities. I am restricted to ws and wss, I'm using node.js with websocket-node at the server and pure javascript at the client.

Upvotes: 2

Views: 982

Answers (1)

kanaka
kanaka

Reputation: 73139

That sounds fairly reasonable (assuming the server to client is truly not secret). I would suggest a couple of variations however:

  • Just keep two WebSocket connections from the client to the server. The first is wss and used for token exchange and client to server commands (which you mentioned could be harmful). If the first connection disconnects or times out, the ws connection should be terminated too.
  • Don't allow any client to server commands/control over the ws connection.
  • Make sure that in addition to timeout, the token can only be used once. Otherwise, an attacker could sniff the ws connection and try and replay the token to gain a connection.

You also need to make sure that your initial wss connection is authorized (not just encrypted). In other words, the server needs to be able to verify that the client is who it says it is and has authorization to make this connection. Also, if the ws connection is truly just for unprotected server to client data that is okay to be sniffed, then it's not the end of the world if an attacker is successfully able to make a connection because they are just using up bandwidth and server CPU (again this is assuming that client to server commands are limited to the wss connection).

Also, I would try benchmarking the server to client connection as both ws and wss. The extra CPU load might be more tolerable than you expect (some embedded devices have SSL/TLS offload in hardware too).

Upvotes: 1

Related Questions