From: Andreas Bartelt <obsd@bartula.de>
Subject: Re: nginx: TLS 1.2-only config doesn't work reliably anymore with nginx [possible bug in nginx, libressl or chrome]
To: Theo Buehler <tb@theobuehler.org>, jsing@openbsd.org, beck@openbsd.org
Cc: Ports Mailing List <ports@openbsd.org>
Date: Fri, 17 May 2024 08:01:00 +0200

Thanks a lot, this patch also fixes the problem in my setup with the TLS 
1.2-only nginx config.

On 5/16/24 20:17, Theo Buehler wrote:
> 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) {