Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
I'm planning to implement (nginx) ssl_session_tickets in addition to ssl_session_cache between a proxy and upstream. They're not located in the same DC so TLS must be in place.
My questions are : 1) as handshakes will only be made between servers, is the key rotation critical as it is when configured for establishing connection between servers and random clients?
and 2) is there any benefit on this, as i'm already using ssl_session_cache and also proxy_ssl_session_reuse?
In 1.2 and below tickets are beneficial if you have so many clients storing sessions on the server takes too much space, or you have multiple server instances (i.e. a 'farm') that must handle traffic from the same client(s) and can't easily share dynamic state but can preshare a key for the tickets. The first doesn't apply upstream of a proxy; the second might, depending on details you didn't tell us.
TLS protects the channel, not the endpoints. If the channel is now consistently over a few (probably more-or-less fixed) networks instead of "all the Internet", that reduces the attack risks to some extent, but whether this is enough to increase key lifetime is a judgement call. But if you're subject to a law, regulation, or policy, for example PCIDSS or HIPAA or GLB, usually the effort to get and maintain an exception is more than the effort of just taking standard precautions even when they aren't needed.
Note in 1.3 both the old session-id resumption AND tickets are replaced by a single new dynamic-PSK method, so this choice becomes moot.
Compare https://crypto.stackexchange.com/questions/15209/compare-rfc-5246-sessionid-re-use-versus-rfc-5077-session-resumption (disclosure: my answer)
