BUG/MEDIUM: ssl: backend TLS resumption with sni and TLSv1.3
authorWilliam Lallemand <wlallemand@haproxy.org>
Wed, 17 Nov 2021 01:59:21 +0000 (02:59 +0100)
committerWilliam Lallemand <wlallemand@haproxy.org>
Tue, 23 Nov 2021 14:44:07 +0000 (15:44 +0100)
commit295b1043dda42d3e5461ea2d58d1e4ea50ae7398
treeace2b94f188d969cc477d8de2a266080a2d19ae6
parent31b6a4661611b21ccec5b62ea778a7a3935cb6ba
BUG/MEDIUM: ssl: backend TLS resumption with sni and TLSv1.3

When establishing an outboud connection, haproxy checks if the cached
TLS session has the same SNI as the connection we are trying to
resume.

This test was done by calling SSL_get_servername() which in TLSv1.2
returned the SNI. With TLSv1.3 this is not the case anymore and this
function returns NULL, which invalidates any outboud connection we are
trying to resume if it uses the sni keyword on its server line.

This patch fixes the problem by storing the SNI in the "reused_sess"
structure beside the session itself.

The ssl_sock_set_servername() now has a RWLOCK because this session
cache entry could be accessed by the CLI when trying to update a
certificate on the backend.

This fix must be backported in every maintained version, however the
RWLOCK only exists since version 2.4.

(cherry picked from commit e18d4e82862eb5c9b54b89f85d4c3b7c82d7395e)
Signed-off-by: William Lallemand <wlallemand@haproxy.org>
(cherry picked from commit c78ac5ade6bdaf46634edf08fecd735ab7d0a5f1)
[wla: ha_free was replaced by free+NULL, some context changed, there is
no server side certificate change on the CLI in 2.3, so the backend
cache is not flushed]
Signed-off-by: William Lallemand <wlallemand@haproxy.org>
include/haproxy/server-t.h
src/ssl_sock.c