Ensure that we specify the correct group when creating a HelloRetryRequest.HEADmaster

When processing the client supported groups and key shares extensions,
the group selection is currently based on client preference. However,
when building a HRR the preferred group is identified by calling
tls1_get_supported_group(). If SSL_OP_CIPHER_SERVER_PREFERENCE is enabled,
group selection will be based on server instead of client preference. This
in turn can result in the server sending a HRR for a group that the client
has already provided a key share for, violating the RFC.

Avoid this issue by storing the client preferred group when processing
the key share extension, then using this group when creating the HRR.

Thanks to dzwdz for identifying and reporting the issue.

ok beck@ tb@

1 files changed, 2 insertions, 1 deletions

diff --git a/src/lib/libssl/ssl_tlsext.c b/src/lib/libssl/ssl_tlsext.c
index 9209597601..12ede899e8 100644
--- a/src/lib/libssl/ssl_tlsext.c
+++ b/src/lib/libssl/ssl_tlsext.c
@@ -1,4 +1,4 @@
-/* $OpenBSD: ssl_tlsext.c,v 1.156 2025/06/07 10:23:21 tb Exp $ */
+/* $OpenBSD: ssl_tlsext.c,v 1.157 2025/10/16 14:42:21 jsing Exp $ */
 /*
  * Copyright (c) 2016, 2017, 2019 Joel Sing <jsing@openbsd.org>
  * Copyright (c) 2017 Doug Hogan <doug@openbsd.org>
@@ -1554,6 +1554,7 @@ tlsext_keyshare_server_process(SSL *s, uint16_t msg_type, CBS *cbs, int *alert)
                 for (j = 0; j < server_groups_len; j++) {
                         if (server_groups[j] == client_groups[i]) {
                                 client_preferred_group = client_groups[i];
+                                s->s3->hs.tls13.server_group = client_preferred_group;
                                 preferred_group_found = 1;
                                 break;
                         }