Hello! On Thu, Oct 29, 2020 at 10:23:33PM +0100, Robert Naundorf wrote:
> I have a question on TLS session resumption with client-side session > tickets and its implementation in nginx. > > RFC 5077, section 3.3, paragraph 2 reads: > If the server successfully verifies the client's ticket, then it MAY renew > the ticket by including a NewSessionTicket handshake message after the > ServerHello in the abbreviated handshake. The client should start using the > new ticket as soon as possible ... > > Which seems very reasonable to me. That way the session could continue > without the need of a costly full handshake. It could continue virtually > forever, as long as the client resumes the session within the time window > configured by ssl_session_timeout. This is not how session timeouts work. Session timeout means that parties have to re-check if the other side still have access to the certificate presented and its private key, certificates haven't been revoked and so on. That is, once session timeout expires, there should be a full handshake. In RFC 5077, relevant section is 5.6. Ticket Lifetime (https://tools.ietf.org/html/rfc5077#section-5.6): The TLS server controls the lifetime of the ticket. Servers determine the acceptable lifetime based on the operational and security requirements of the environments in which they are deployed. The ticket lifetime may be longer than the 24-hour lifetime recommended in [RFC4346]. TLS clients may be given a hint of the lifetime of the ticket. Since the lifetime of a ticket may be unspecified, a client has its own local policy that determines when it discards tickets. It refers to RFC 4346, which further explains where 24-hour limit comes from (https://tools.ietf.org/html/rfc4346#appendix-F.1.4): Sessions cannot be resumed unless both the client and server agree. If either party suspects that the session may have been compromised, or that certificates may have expired or been revoked, it should force a full handshake. An upper limit of 24 hours is suggested for session ID lifetimes, since an attacker who obtains a master_secret may be able to impersonate the compromised party until the corresponding session ID is retired. Applications that may be run in relatively insecure environments should not write session IDs to stable storage. Renewing tickets is not about avoiding full handshakes, but rather about returing an updated ticket to the client - for example, to update the key used to encrypt tickets. -- Maxim Dounin http://mdounin.ru/ _______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
