Welcome! Log In Create A New Profile

Advanced

Re: [PATCH 11 of 11] SSL: automatic rotation of session ticket keys

Maxim Dounin
October 01, 2022 05:00AM
Hello!

On Thu, Sep 29, 2022 at 08:00:03PM +0400, Sergey Kandaurov wrote:

> > On 28 Sep 2022, at 22:37, Maxim Dounin <mdounin@mdounin.ru> wrote:
> >
> > On Mon, Sep 26, 2022 at 02:17:18PM +0400, Sergey Kandaurov wrote:

[...]

> >> And by the way, while reviewing this patch, I noticed that
> >> OpenSSL doesn't allow a client to gracefully renew TLSv1.2 session
> >> when the client receives a new session ticket in resumed sessions.
> >> In practice, it is visible when client resumes a not yet expired
> >> session encrypted with not a fresh ticket key (after rotation),
> >> which results in sending a new session ticket.
> >> See ssl_update_cache() for the !s->hit condition.
> >> In the opposite, BoringSSL always allows to renew TLSv1.2 sessions.
> >
> > You mean on the client side? Yes, it looks like
> > ngx_ssl_new_client_session() won't be called for such a new
> > session ticket, and updated ticket will be never saved. This
> > might need to be worked around.
>
> Yes, I mean the client side.
>
> >
> > This should be safe with the key rotation logic introduced in this
> > patch though, given that the previous key is preserved till the
> > last ticket encrypted with it is expected to expire.
> >
> > One of the possible solutions might be to avoid re-encryption of
> > tickets with the new key, as the old key is anyway expected to be
> > available till the session expires.
>
> I don't think it's worth the effort. If I got you right, and
> as far as I understand, re-encrypting the ticket essentially
> means sending a fresh session (renewal).

Well, not really. Re-encryption of a ticket does not imply
session renewal. Further, doing so implies security risk: if we
renew a session during re-encryption, this makes it possible to
create essentially infinite sessions. And, for example, if a
session used a client certificate, this effectively means that
this certificate will never expire and cannot be revoked.

With TLSv1.2, OpenSSL follows this logic: session expiration time
is set when a session is created, and ticket re-encryption only
re-encrypts the session, but doesn't change session expiration.
As such, any certificate validation which happens during session
creation needs to be redone once session timeout expires - and
this makes it possible to implement certificate revocation.

On the other hand, as implemented for TLSv1.3 at least in OpenSSL
it seems not to be the case. Every ticket sent to the client
actually creates a new session with _updated_ expiration time. As
such, it is possible to create a session authenticated with a client
certificate, and use this session indefinitely, even after the
certificate will expire and/or will be revoked.

This seems to be a security issue in OpenSSL.

BoringSSL seems to behave similarly with TLSv1.3, that is, it
updates session expiration time, making it possible to use an
authenticated session for much longer than session timeout
configured. But BoringSSL also has session's auth_timeout, which
prevents indefinite use of the session. The auth_timeout value is
hardcoded to 7 days (SSL_DEFAULT_SESSION_AUTH_TIMEOUT), and does
not seem to be adjustable (only with SSL_SESSION_set_timeout(),
which is documented to be a function for writing tests).

I would rather say it is also a security issue in BoringSSL,
though it's slightly better than in OpenSSL due to the 7 days
limit.

> Avoid doing that will
> result in eventual session expiration and a full SSL handshake.
> Please correct me if I'm wrong.

It is expected to result in a full SSL handshake when session
timeout expires, see above. With TLSv1.2, re-encryption is
expected to switch tickets to the new key faster, without waiting
for the full session timeout, so one can throw away the old key
faster (at a cost of not being able to decrypt some valid tickets
which weren't re-encrypted though). Avoiding re-encryption might
save some useless work on re-encryption itself which might not be
really needed due to the client-side issue you've mentioned. It's
at most a minor optimization though.

It is more complicated with TLSv1.3 though, both due to the issue
outlined above and the fact that tickets are often used just once,
notably with Chrome (see https://trac.nginx.org/nginx/ticket/1892
for details).

[...]

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx-devel mailing list -- nginx-devel@nginx.org
To unsubscribe send an email to nginx-devel-leave@nginx.org
Subject Author Views Posted

[PATCH 11 of 11] SSL: automatic rotation of session ticket keys

Maxim Dounin 514 August 25, 2022 11:14PM

Re: [PATCH 11 of 11] SSL: automatic rotation of session ticket keys

Sergey Kandaurov 61 September 15, 2022 01:52AM

Re: [PATCH 11 of 11] SSL: automatic rotation of session ticket keys

Maxim Dounin 58 September 16, 2022 05:10PM

Re: [PATCH 11 of 11] SSL: automatic rotation of session ticket keys

Sergey Kandaurov 176 September 26, 2022 06:18AM

Re: [PATCH 11 of 11] SSL: automatic rotation of session ticket keys

Maxim Dounin 52 September 28, 2022 02:38PM

Re: [PATCH 11 of 11] SSL: automatic rotation of session ticket keys

Sergey Kandaurov 57 September 29, 2022 12:02PM

Re: [PATCH 11 of 11] SSL: automatic rotation of session ticket keys

Maxim Dounin 46 October 01, 2022 05:00AM

Re: [PATCH 11 of 11] SSL: automatic rotation of session ticket keys

Maxim Dounin 45 October 09, 2022 01:00AM

Re: [PATCH 11 of 11] SSL: automatic rotation of session ticket keys

Sergey Kandaurov 39 October 12, 2022 09:58AM

Re: [PATCH 11 of 11] SSL: automatic rotation of session ticket keys

Maxim Dounin 38 October 12, 2022 02:08PM



Sorry, you do not have permission to post/reply in this forum.

Online Users

Guests: 84
Record Number of Users: 6 on February 13, 2018
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready