[PATCH] SSL: always renewing tickets with TLSv1.3 (ticket #1892)

Maxim Dounin mdounin at mdounin.ru
Mon Jan 24 14:24:01 UTC 2022


Hello!

On Mon, Jan 24, 2022 at 03:35:18PM +0300, Sergey Kandaurov wrote:

> > On 21 Jan 2022, at 06:57, Maxim Dounin <mdounin at mdounin.ru> wrote:
> > 
> > # HG changeset patch
> > # User Maxim Dounin <mdounin at mdounin.ru>
> > # Date 1642737110 -10800
> > #      Fri Jan 21 06:51:50 2022 +0300
> > # Node ID cff51689a4a182cb11cba2eb9303e2bc21815432
> > # Parent  96ae8e57b3dd1b10f29d3060bbad93b7f9357b92
> > SSL: always renewing tickets with TLSv1.3 (ticket #1892).
> > 
> > Chrome only use TLS session tickets once with TLS 1.3, likely following
> 
> uses ?

Fixed, thnx.

> > RFC 8446 Appendix C.4 recommendation.
> 
> Besides that, there's a study [1] that discusses 3rd-party
> tracking via session resumption.  Although improvements
> in TLS 1.3 that provide different PSK identities in session
> tickets are used to protect against correlation by a passive
> observer, the study suggests to completely deactivate TLS 1.3
> session resumption for privacy reasons.

Sure, but this is certainly unrelated to Chrome behaviour, since 
it does accept and use new session tickets, thus allowing infinite 
tracking.

> This might be also due to 0-RTT Anti-Replay guidance in case
> the selection from available tickets is agnostic to 0-RTT.
> Practical analysis in [2] demonstrates that Chrome(ium) indeed
> selects among tickets never used before.  It doesn't make clear
> separation, though, whether this depends on sending 0-RTT.

The particular behaviour was observed with 0-RTT disabled on the 
server ("ssl_early_data off;", the default), so browser knows in 
advance that 0-RTT is not going to be used.  While it might be the 
reason, this would be suboptimal behaviour.

> [1] https://arxiv.org/abs/1810.07304
> [2] "A Survey of TLS 1.3 0-RTT Usage", Mihael Liskij
> 
> >  With OpenSSL, this works fine with
> > built-in session tickets, since these are explicitly renewed in case of
> > TLS 1.3 on each session reuse, but results in only two connections being
> > reused after an initial handshake when using ssl_session_ticket_key.
> > 
> > Fix is to always renew TLS session tickets in case of TLS 1.3 when using
> > ssl_session_ticket_key, similarly to how it is done by OpenSSL internally.
> > 
> > diff --git a/src/event/ngx_event_openssl.c b/src/event/ngx_event_openssl.c
> > --- a/src/event/ngx_event_openssl.c
> > +++ b/src/event/ngx_event_openssl.c
> > @@ -4448,7 +4448,21 @@ ngx_ssl_session_ticket_key_callback(ngx_
> >             return -1;
> >         }
> > 
> > -        return (i == 0) ? 1 : 2 /* renew */;
> > +        /* renew if TLSv1.3 */
> > +
> > +#ifdef TLS1_3_VERSION
> > +        if (SSL_version(ssl_conn) == TLS1_3_VERSION) {
> > +            return 2;
> > +        }
> > +#endif
> > +
> > +        /* renew if non-default key */
> > +
> > +        if (i != 0) {
> > +            return 2;
> > +        }
> > +
> > +        return 1;
> >     }
> > }
> > 
> 
> Looks good.

-- 
Maxim Dounin
http://mdounin.ru/



More information about the nginx-devel mailing list