nginx 1.18.0 implicitly enables TLS 1.3 (with only "ssl_protocols TLSv1.2; " in nginx.conf config)

[Thomas Ward]

We had this problem in Ubuntu's repos until we rebuilt against newer OpenSSL and the TLS 1.3 variables were exposed to NGINX at build time - then you could turn it off in ssl_protocols by not specifying TLSv1.3.However, your case indicates that you are linked (compiled) against older LibreSSL than you are running.  NGINX can't know what newer items are available without a recompile.  This applies to OpenSSL as well.  Its not just what version of the SSL libraries you are running - its what version of the libs you compiled with as well.Sent from my Sprint Samsung Galaxy Note10+.
-------- Original message --------From: nginx at bartelt.name Date: 11/29/20  10:01  (GMT-05:00) To: nginx at nginx.org Subject: nginx 1.18.0 implicitly enables TLS 1.3 (with only "ssl_protocols
  TLSv1.2; " in nginx.conf config) Hello,I've noticed that nginx 1.18.0 always enables TLS 1.3 even if not configured to do so. I've observed this behavior on OpenBSD with (nginx 1.18.0 linked against LibreSSL 3.3.0) and on Ubuntu 20.04 (nginx 1.18.0 linked against OpenSSL 1.1.1f). I don't know which release of nginx introduced this bug. From nginx.conf:ssl_protocols TLSv1.2;--> in my understanding, this config statement should only enable TLS 1.2 but not TLS 1.3. However, the observed behavior is that TLS 1.3 is implicitly enabled in addition to TLS 1.2.Best regardsAndreas# nginx -Vnginx version: nginx/1.18.0built with LibreSSL 3.2.2 (running with LibreSSL 3.3.0)_______________________________________________nginx mailing listnginx at nginx.orghttp://mailman.nginx.org/mailman/listinfo/nginx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20201129/b5f64ed4/attachment.htm>