Securing Websockets

问题:

Right now our application is designed to facilitate all communication via websockets after the initial load.

We are trying to figure out a solution to safely pass sensitive data via this transport.

So far we are thinking about a few things:

1. Authentication of the websocket transport by passing back a unique hash stored in a session cookie delivered via SSL on initial load.

2. Client-side encryption using something like a javascript bcrypt implementation to encrypt everything before it is transported.

3. Just passing all sensitive data with a normal post via SSL even though we dont want to.

Something like number 1 would be the best outcome but we are unaware if websokets are vulnerable to things like man in the middle attacks even after authentication.

Any help sussing out possible security downfalls, or any other ideas on how to achieve true security over websockets would be greatly appreciated!

回答1:

Connecting to a wss:// WebSocket URL rather than ws:// will use the browser's standard TLS/SSL encryption to connect to the server. It's equivalent to HTTPS vs HTTP. If you trust your browser's SSL/TLS implementation then you can trust WebSocket wss:// connections since they use the same engine. You will need to have a signed SSL certificate configured with your websocket server, but that's pretty much required anyways.

回答2:

Securing(encrypting using SSL/TLS) is very import for your data. But you should consider authentication as well. Anyone with ws capable device that know your endpoint for your server will be able to get data if it doesn't require authentication first. See http://simplyautomationized.blogspot.com/2015/09/5-ways-to-secure-websocket-rpi.html Includes a 3-way handshake method (CHAP) which requires both client and server to have a "pre-shared secret".
Other ways are detailed on the post.

Cheers

回答3:

With regard to cookies, it might be worth considering, that (currently), the WebSockets protocol spec does not require a browser to provide all, or even any of the cookies that were set by the web server originally serving the JavaScript you use to open a WebSockets connection to that server.

See here for a description of how Firefox behaves (from a FF developer).