BUG/MEDIUM: ssl: take care of second client hello
authorWilly Tarreau <w@1wt.eu>
Thu, 9 Oct 2025 14:13:18 +0000 (16:13 +0200)
committerWilly Tarreau <w@1wt.eu>
Fri, 10 Oct 2025 14:43:45 +0000 (16:43 +0200)
commitcec6b5c14777d85ece2117eb1b3a5227f9ca7fe3
tree285b0f203b4c83e7d561632b07a354537f5313da
parent4801b1e5928f677ed73e8dba0bd6b20b20f51d79
BUG/MEDIUM: ssl: take care of second client hello

For a long time we've been observing some sporadic leaks of ssl-capture
pool entries on haproxy.org without figuring exactly the root cause. All
that was seen was that less calls to the free callback were made than
calls to the hello parsing callback, and these were never reproduced
locally.

It recently turned out to be triggered by the presence of "curves" or
"ecdhe" on the "bind" line. Captures have shown the presence of a second
client hello, called "Change Cipher Client Hello" in wireshark traces,
that calls the client hello callback again. That one wasn't prepared for
being called twice per connection, so it allocates an ssl-capture entry
and assigns it to the ex_data entry, possibly overwriting the previous
one.

In this case, the fix is super simple, just reuse the current ex_data
if it exists, otherwise allocate a new one. This completely solves the
problem.

Other callbacks have been audited for the same issue and are not
affected: ssl_ini_keylog() already performs this check and ignores
subsequent calls, and other ones do not allocate data.

This must be backported to all supported versions.

(cherry picked from commit 336170007c280ac7e8c8edc413f10cbb78af0ec5)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit c3974c9da408fe1d387ad333a32fdf062ceb41eb)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 1a9cddac05fe90d7299d2a84c00bae290dc14d42)
Signed-off-by: Willy Tarreau <w@1wt.eu>
src/ssl_sock.c