nginx: TLS 1.2-only config doesn't work reliably anymore with nginx [possible bug in nginx, libressl or chrome]

[Andreas Bartelt]

Hi,

I've chosen to report to ports@ first since I'm not yet sure what's the 
best mailing list for the kind of problem I've been observing recently.

I've deliberately been using a TLS 1.2-only (i.e., no TLS 1.3 support) 
configuration with nginx for multiple years now and my (previously 
working) TLS 1.2 config from nginx.conf looks like the following:
        ssl_protocols TLSv1.2;
        ssl_ciphers 
ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384;
        ssl_prefer_server_ciphers   off;
        ssl_ecdh_curve prime256v1;

On OpenBSD current and with the following application versions (nginx 
1.26.0, LibreSSL 3.9.0, chromium-124.0.6367.201), I've noticed that a 
significant fraction of HTTPS connections via chrome fail via illegal 
parameter alert (but not all of them). All HTTPS connections still work 
perfectly fine via firefox-125.0.3 as well as SSL Labs site from Qualys.

I could get rid of these problems (with TLS access to nginx via chrome) 
by also enabling TLS 1.3 in nginx.conf:
        ssl_protocols TLSv1.2 TLSv1.3;
        ssl_ciphers 
TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384;
        ssl_prefer_server_ciphers   off;
        ssl_ecdh_curve prime256v1;

It might be possible that also enabling TLS 1.3 simply masks the current 
problem with TLS 1.2 support.

Can anybody reproduce this problem?
Any ideas on how to locate the actual source of this bug?

Best regards
Andreas