After the initial shared secret is agreed upon between the client an server through the TLS handshake does the shared secret get rotated periodically ?
-
3I think the following quote from http://security.stackexchange.com/questions/6028/server-to-server-encryption-key-rotation-over-the-air-can-it-improve-security will answer this: "for the truly paranoid who wants to get a warm fuzzy feeling of safety out of ritual cryptographic incantations, you can just negotiate a new handshake over an existing session, at any time you want." – childofsoong May 03 '16 at 07:34
2 Answers
The client or the server may request a renegotiation at any time. That renegotiation would include a new shared secret.
The Server can send a Hello Request to trigger renegotiation (emphasis mine):
The HelloRequest message MAY be sent by the server at any time.
Meaning of this message:
HelloRequest is a simple notification that the client should begin the negotiation process anew. In response, the client should send a ClientHello message when convenient.
To quote RFC 5246 on Client Hello (empasis mine):
When a client first connects to a server, it is required to send the ClientHello as its first message. The client can also send a ClientHello in response to a HelloRequest or on its own initiative in order to renegotiate the security parameters in an existing connection.
How likely an application is to request renegotiation is going to vary, but (unscientifically) I expect the answer is "most won't ask." But it can be done.
Between a single client and server, the "shared secret" (mastersecret) will have last for the session.
Session Resumption may be allowed via Session IDs as described in RFC5247 and RFC4346 or Transport Layer Security (TLS) Session Resumption without Server-Side State is described in RFC 5077 allows The ticket lifetime may be longer than the 24-hour lifetime recommended in [RFC4346]
RFC5247 (obsoletes RFC4346 but they say the same thing) states: "An upper limit of 24 hours is suggested for session ID lifetimes"
-jim