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
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx