tree 3eca9e39e315e1d48503db754f9c5273b826f70a
parent e18d4e82862eb5c9b54b89f85d4c3b7c82d7395e
author William Lallemand <wlallemand@haproxy.org> 1637253986 +0100
committer William Lallemand <wlallemand@haproxy.org> 1637290796 +0100

BUG/MEDIUM: ssl: abort with the correct SSL error when SNI not found

Since commit c2aae74 ("MEDIUM: ssl: Handle early data with OpenSSL
1.1.1"), the codepath of the clientHello callback changed, letting an
unknown SNI escape with a 'return 1' instead of passing through the
abort label.

An error was still emitted because the frontend continued the handshake
with the initial_ctx, which can't be used to achieve an handshake.
However, it had the ugly side effect of letting the request pass in the
case of a TLS resume. Which could be surprising when combining strict-sni
with the removing of a crt-list entry over the CLI for example. (like
its done in the ssl/new_del_ssl_crlfile.vtc reg-test).

This patch switches the code path of the allow_early and abort label, so
the default code path is the abort one, letting the clientHello returns
the correct SSL_AD_UNRECOGNIZED_NAME in case of errors.

Which means the client will now receive:

	OpenSSL error[0x14094458] ssl3_read_bytes: tlsv1 unrecognized name

Instead of:

	OpenSSL error[0x14094410] ssl3_read_bytes: sslv3 alert handshake failure

Which was the error emitted before HAProxy 1.8.

This patch must be carrefuly backported as far as 1.8 once we validated
its impact.