Reputation: 3520
I'm looking to host some websocket based applications, which should only be accessible via an https page. As such, the server generates the https page with a random key inside. I want to use this key to protect against someone from the outside from accessing the websockets indirectly.
I could have each web socket client send the key to the websocket servers, and close the connection if the key does not match. I would prefer, however, to update the websockets themselves to pass the key, and automatically reject the connection if the key does not match. (this way, if a new app is introduced, there's no chance of forgetting to implement the check).
I've looked around, and am not finding much in-depth documentation on how websockets work.
Is the initial handshake of a wss connection sent in the clear (if I attached the key to those packets, could a man-in-the-middle intercept them?). If not, is there a standard way to send this sort of meta data on the connection, or should I just hack the websocket source files?
I'm using libwebsockets on the server side, and jquery.websockets for the client side.
Upvotes: 0
Views: 624
Reputation: 160033
Secure WebSocket connections are only upgraded after the secure connection is established:
- If /secure/ is true, the client MUST perform a TLS handshake over the connection after opening the connection and before sending the handshake data [RFC2818]. If this fails (e.g., the server's certificate could not be verified), then the client MUST Fail the WebSocket Connection and abort the connection. Otherwise, all further communication on this channel MUST run through the encrypted tunnel [RFC5246].
Clients MUST use the Server Name Indication extension in the TLS
handshake [RFC6066].
On the client-side the WebSocket
interface is provided by the browser - by the time you get to the onopen
event the handshake has already completed. You could put the key in the protocol
, but that would definitely be a hack (since protocol
is meant to be used for actual registered protocols, not authentication mechanisms).
The alternative is simply to wrap the WebSocket in your own library that handles the key exchange on the first message so that your application layer doesn't have to worry about the details.
Upvotes: 1