Skip to content

Tls mem 2 - #54

Closed
Frauschi wants to merge 3 commits into
masterfrom
tls_mem_2
Closed

Frauschi wants to merge 3 commits into
masterfrom
tls_mem_2

Conversation

@Frauschi

Copy link
Copy Markdown
Owner

Description

Please describe the scope of the fix or feature addition.

Fixes zd#

Testing

How did you test?

Checklist

  • added tests
  • updated/added doxygen
  • updated appropriate READMEs
  • Updated manual and documentation

@Frauschi Frauschi self-assigned this Oct 13, 2026
Comment thread src/tls.c Outdated
The supported groups extension stored its named groups as a linked list with
one node per two byte group identifier. A client advertising 16 groups made 16
allocations for 32 bytes of wire data, and a server made a second set of nodes
for the intersection with the client's list. Every insert also walked the list
to check for a duplicate.

Replace the list with a single block holding a count, a capacity and a flat
array of names. The block starts with room for four names and doubles when a
build advertises more, so a handshake normally makes one allocation per list.
Inserts and lookups index the array instead of chasing pointers, and freeing
the extension is a single XFREE.
A server with its own supported groups list built a second list holding the
groups it has in common with the client, swapped that into the extension and
freed the original. Now that the groups are a flat array, the common ones are
moved to the front of the server's own list instead, so the intersection needs
no allocation.

The kept groups stay in the client's order, as before. A name that has already
been moved sits outside the range still searched, so a group repeated in the
client list is added once.

Adds a test for the resulting list and for the TLS 1.2 handshake failure when
no group is common.
Before sending EncryptedExtensions a TLS 1.3 server checked whether the client
offered the group the server prefers most. It answered that by populating a
whole temporary extension list with every group this build offers, reading the
first name out of it, and freeing the list again. The TLS 1.2 FFDHE selection
did the same to find the highest priority group both sides have. Both cost a
TLSX node, a groups block and a walk of the full preference chain on every
handshake.

Turn the preference chain into TLSX_WalkSupportedGroups(), which calls a
callback for each group in the same order. Populating an extension list is now
one caller of the walk, finding the preferred group is another that stops at
the first group, and the FFDHE selection is a third that stops at the first
group the client also has. The server builds a list only in the case that
sends it back to the client.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant