Hello! On Sun, Apr 12, 2020 at 10:12:48PM +0300, Alexander Smirnov wrote:
> I have found that in TLS 1.3 mode nginx doesn't fully disable session > tickets even with > > session_tickets off; > > According to https://www.openssl.org/docs/man1.1.1/man3/SSL_get_options.html > > > SSL_CTX_set_options(conf->ssl.ctx, SSL_OP_NO_TICKET); > > is not enough to disable session tickets. It only disables stateless > tickets but preserves stateful ones. > > It can be easily verified with > > openssl s_client -connect localhost:443 > > Nginx still returns session tickets. > > To fully disable tickets > > SSL_CTX_set_num_tickets(conf->ssl.ctx, 0); > > should also be called. > > I am not sure on changes. Not sure if I fully understand your intentions on > this nginx behaviour. Could you please review the proposed patch ? In TLS 1.3, a separate field for session identifiers was removed, and TLS session tickets are used instead. "Stateful" tickets are essentially what is called "sessions" in TLS 1.2 and before. Since most configuration with disabled tickets rely on session resumption to work via session identifiers, disabling session tickets completely in TLS 1.3 due to "ssl_session_tickets off;" in the configuration is not a good idea. And this is essentially why SSL_OP_NO_TICKET does not disable tickets completely as well - instead, it only disables stateless tickets, which is what was used to be known as "tickets" in TLS 1.2 and before. If for some reason you really want to disable session resumption in TLS 1.3 completely, you may do so in the same way it can be done for previous protocols: by using "ssl_session_cache off; ssl_session_tickets off;". This results in SSL_CTX_set_session_cache_mode(ctx, SSL_SESS_CACHE_OFF); SSL_CTX_set_options(ctx, SSL_OP_NO_TICKET); on the SSL context, so it should be enough for the OpenSSL library to understand that neither stateful nor stateless tickets should be used. Currently it still sends meaningless stateless tickets, not sure why, but probably this is something to be addressed in OpenSSL, not nginx. -- Maxim Dounin http://mdounin.ru/ _______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel