How long has the secure TCP secure channel been protected?

We have a web service that acts as a gateway between our customers and another service. Customers send messages and receive random messages from a third-party service. The client server opens the channel to our web server via a secure socket to receive incoming messages (and should not poll the server every few minutes).

My question is: is it safe to leave this channel unlimitedly open, or should we periodically close and reopen it to receive new credentials (session keys)? If the latter, how often (hourly, daily, weekly) will be considered "best practice"? I found a lot of information about secure connections, but did not answer this specific question.

thanks

+7
source share
1 answer

SSL / TLS (which I assume you are talking here) does NOT automatically update / rewrite session keys used. There is a protocol revision built into the protocol that allows you to change session keys during an active session, but this procedure found a significant vulnerability several years ago, and the revision process was changed ( in RFC 5746, see here ) to solve the problem. If you want to revise the session keys for SSL / TLS, make sure that you do this as described in this RFC.

This, however, does not answer your initial IF question, session keys must be changed. The answer ... it depends on your security requirements. A good guideline for use is that any encrypted communication can ultimately be decrypted if you see enough encrypted data (how practical / feasible this can vary greatly). So changing your keys so often is very good. If you transfer a small amount of data over a secure connection, and the data is not so sensitive, then you may not leave with it on a regular basis (indeed, your SSL / TLS session will probably be broken and rest due to timeouts on one from two sides on a regular basis anyway ...). If you have a very sensitive data set and you send a lot of data, I suggest turning the keys every day or so to mitigate this risk (just do it in a safe way).

+4
source

All Articles