12

I am far from being a security expert, so please forgive any approximation in this question.

As I understand it from this (very good) answer, a suite of HTTPS connection can be summarized as such :

  1. There's a negotiation between the browser and the server that uses expensive asymmetric cryptography that results in a shared master secret that will last for the time of a "session", time which is decided by the server.
  2. Each subsequent connection is then encrypted with a fast symmetric cryptography algorithm whose key is inferred from the master secret. Therefore each connection is encrypted with a different key so any "sniffer" would not have enough data to find either the specific connection key or the master secret.

Now, I'm working on an application that will use web sockets that may stay connected for very long periods of time. By very long, I mean several days. The informations that will transit through this web socket connection will be highly confidential.

So, knowing that a WebSocket should never disconnect, is there something in the WSS specification to periodically renew the symmetric key ?
As I understand it, with a symmetric algorithm, the more data are encrypted with the same key, the weaker the encryption becomes.

HTTPS changes this key (infers a new one from the master secret) at each new connection, but what about a WebSocket connection where there's only one connection for a long period of time ?

4

Unless you're sending on the order of exabytes through that connection, AES should not degrade in security over that time frame. The duration that the WebSocket is open doesn't degrade it's security, so only the data flow through it may eventually (after a lot of use) erode the security given by AES. Keep in mind that the entire Internet generated about 1,000 exabytes per day, so unless you're routing a very significant percentage of all Internet traffic through that one WebSocket you should not need to renew your keys ever during the usage of the WebSocket.

If you still want to renew the keys the client or server may, at any time during the connection, re-issue a handshake request which re-derives master keys based on two new random values. RFC5246

  • Does the browser do that automatically after a certain period of time ? – Salomon BRYS Mar 11 '16 at 16:03
  • @SalomonBRYS Considering how the vast majority of WebSockets won't send more than the threshold where AES starts to degrade in security and that the handshakes are the most computationally expensive part of the whole process I would guess that they don't. There really isn't any reason to want to given those facts. – sethmlarson Mar 11 '16 at 16:06
  • 2
    Another comparison to the OP's question are other long-lived encrypted connections, such as SSH tunnels, SFTP sessions, FTPS uploads/downloads, etc. The particular protocol (e.g. WebSockets) in question is not as relevant as the encryption protocols used, and both TLS and SSH have rekeying/rehandshake capabilities. – Castaglia Mar 11 '16 at 21:37

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.