Hello,
Is there an ACL directive or method to add the client ip address to a stick-table who logs an “SSL handshake failure” ?
On a test system TLSv1.3 is forced using “ssl-default-bind-options force-tlsv13” . The result is TLSv1.2 and earlier clients fail to connect logging “SSL handshake failure”, as is expected. Since the TLSv1.2 and earlier clients never negotiate the TLS connection, the standard ACL methods to look for TLS details like client ciphers do not work.
I am wondering if I can build an haproxy ACL to add that client ip address (11.22.33.44) to a stick-table for actions to be decided on the next connection. Is there a generic “ssl error” check I have overlooked? Maybe Haproxy denies the TLSv1.2 connection so early that ACLs do not evaluate? I tried quite a few directives in the HAProxy v2.4 configuration manual without success.
global
daemon
ssl-default-bind-ciphersuites TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256
ssl-default-bind-options force-tlsv13 prefer-client-ciphers no-tls-tickets
backend gatekeeper
stick-table type ipv6 size 1m expire 75m store gpc0,conn_cnt,conn_rate(75m),conn_cur,http_req_cnt,http_req_rate(75m),http_err_rate(75m)
frontend gateway
mode tcp
option tcplog
bind :443
tcp-request inspect-delay 5s
#
# ACL - "SSL handshake failure" clients
acl handerror < Some "SSL handshake failure" check >
acl trigger src_inc_gpc0(gatekeeper) gt 0
tcp-request connection reject if handerror trigger
#
default_backend fe_https
Haproxy does know the client ip address (11.22.33.44) that failed to connect because haproxy logs that information similar to the following:
May 10 10:00:00 local0.info haproxy[35]: 11.22.33.44:12345 [10/May/2022:10:00:00.000] fe_https/1: SSL handshake failure
Thank you for your time. Any tips or pointers to the configuration manual are welcome.
# haproxy -V
HAProxy version 2.4.16-9d532c4 2022/04/29
1 post - 1 participant
