HAproxy SSL handshake failure

user_12622420 0
Viewed 7490

when i use HAproxy as load balancer, at HTTP termination mode and i tail log of it

(tail -f /var/log/haproxy.log). There are 2 types of log appearing

[time] frontend_name/1: SSL handshake failure

and

[time] frontend_name~ message

frontend_name is name follow frontend keyword config in /etc/haproxy/haproxy.cfg

I don't know what /1 and ~ in log message is, and why SSL handshake failure appearing at log has ~ Can someone help me explain and fix this error? Thanks!

frontend handshake haproxy config ssl
1 Answers

~ after frontend name means connection has been established using SSL/TLS
You can find reference to it in %ft entry in the table at: https://cbonte.github.io/haproxy-dconv/2.4/configuration.html#8.2.4
About /1 in frontend_name/1: SSL handshake failure:
I can't find it in the docs, but by experimenting i found it's the number of port in frontend, to which connection was attempted and SSL handshake failed.
For config:

frontend frontend_name
  bind *:443,*:444 ssl crt <path_to_cert>
  bind *:445 ssl crt <path_to_cert> no-tlsv13

If i make TLS1.3 connection to port 445 (e.g. openssl s_client -connect 127.0.0.1:445 -tls1_3), i will get:

frontend_name/3: SSL handshake failure

because 445 is 3. port listed in this frontend.

[UPDATE]
I found a bit more. Error log format explains that /1 in frontend_name/1 is bind_name and can be declared:

bind *:443,*:443 ssl crt <path_to_cert> no-tlsv13 name bind_ssl_foo

will result in frontend-name/bind_ssl_foo: SSL handshake failure.
Unfortunately we can't change error log format.

To learn more we have to make that connection successful and that most likely requires us to lower security (FOR DEBUGGING ONLY!). Normal clients will still negotiate highest security they can, TLS 1.2 or 1.3.

bind *:443 ssl crt <path_to_cert> ssl-min-ver TLSv1.0

Since haproxy 2.2 default for ssl-min-ver is TLSv1.2.
Second step is to log SSL version, negotiated cipher and maybe whole cipherlist send by client by appending %sslv %sslc and maybe %[ssl_fc_cipherlist_str] to your log-format:

log-format "your_log_format_here %sslv %sslc %[ssl_fc_cipherlist_str]"

If you don't have your own log format you can extend HTTP format:

log-format "%ci:%cp [%tr] %ft %b/%s %TR/%Tw/%Tc/%Tr/%Ta %ST %B %CC %CS %tsc %ac/%fc/%bc/%sc/%rc %sq/%bq %hr %hs %{+Q}r %sslv %sslc %[ssl_fc_cipherlist_str]"

To use ssl_fc_cipherlist_str we need to set tune.ssl.capture-cipherlist-size 800 in global section, because default is 0. sslv is SSL/TLS version client connected with.
sslc is SSL/TLS cipher client connected with. ssl_fc_cipherlist_str is cipher list client offered when negotiating SSL/TLS connection. It can be long. Use if you are extra curious.

That will append to your logs info like this:

TLSv1 ECDHE-RSA-AES256-SHA ECDHE-ECDSA-AES256-SHA,ECDHE-RSA-AES256-SHA,DHE-RSA-AES256-SHA,ECDHE-ECDSA-AES128-SHA,ECDHE-RSA-AES128-SHA,DHE-RSA-AES128-SHA,AES256-SHA,AES128-SHA,TLS_EMPTY_RENEGOTIATION_INFO_SCSV

Match by IP previous errors with current entries and you will know what TLS version and ciphers they were using. Then decide whether to adjust your ciphers or force this client to upgrade their SSL software.

So all required changes below:

global
  log /dev/log daemon
  tune.ssl.capture-cipherlist-size 800

frontend frontend_name
  bind *:443 ssl crt <path_to_cert> ssl-min-ver TLSv1.0
  log-format "%ci:%cp [%tr] %ft %b/%s %TR/%Tw/%Tc/%Tr/%Ta %ST %B %CC %CS %tsc %ac/%fc/%bc/%sc/%rc %sq/%bq %hr %hs %{+Q}r %sslv %sslc %[ssl_fc_cipherlist_str]"
  mode http
  (...)

Again, lower security only for debugging if this connection error really is a problem for you.

user_144615310
Related