On Thu, May 16, 2024 at 04:41:05PM +0200, Andreas Bartelt wrote: > 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?
It's a side effect of https://github.com/openbsd/src/commit/be89428ce5fb176ef7adb0cb4f297af5f2b0fb91 Specifically, this check is hit: if (!client_sent_group) { *alert = SSL_AD_ILLEGAL_PARAMETER; return 0; } https://github.com/openbsd/src/blob/master/lib/libssl/ssl_tlsext.c#L1587-L1590 One workaround is to move this check a few lines down so it is only triggered for TLSv1.3. The problem is that with TLSv1.2 s->hit can be set and at the same time no supported groups available in s->session, so tls1_get_group_list(s, 1, &client_groups, &client_groups_len); returns NULL client_groups and length 0, so client_sent_group is never set. I can no longer reproduce the problem with the diff below, but it seems just as plausible that tls_keyshare_server_process() needs special s->hit handling. Index: ssl_tlsext.c =================================================================== RCS file: /cvs/src/lib/libssl/ssl_tlsext.c,v diff -u -p -r1.149 ssl_tlsext.c --- ssl_tlsext.c 16 Apr 2024 17:46:30 -0000 1.149 +++ ssl_tlsext.c 16 May 2024 18:06:56 -0000 @@ -248,7 +248,7 @@ tlsext_supportedgroups_server_process(SS if (groups_len > TLSEXT_MAX_SUPPORTED_GROUPS) goto err; - if (s->hit) + if (s->hit && s->session->tlsext_supportedgroups_length > 0) goto done; if (s->s3->hs.tls13.hrr) {
