On 2015-10-04 13:19, Cyril Bonté wrote:
Hi,
Le 04/10/2015 17:16, Julien Vehent a écrit :
Hi everyone,
I'm working on a configuration that routes to a different backend
based
on the TLS version, using:
acl modern_tls req_ssl_ver 3.3
However, it appears that the acl never returns true. I'm testing with:
$ openssl s_client -connect <target>:443 -servername <target>
-tls1_2
I tried various syntax too, such as "req_ssl_ver 3.3:3.99", but none
work.
Am I misusing this ACL? My configuration is below. Build version at
the
bottom of this email.
frontend https-in
bind 0.0.0.0:443
mode tcp
tcp-request inspect-delay 5s
tcp-request content accept if { req_ssl_hello_type 1 }
acl sni_jve req.ssl_sni -i jve.linuxwall.info
acl sni_mig req.ssl_sni -i mig.ninja
acl modern_tls req_ssl_ver 3.3
use_backend mig_https if sni_mig modern_tls
use_backend jve_https if sni_jve modern_tls
# fallback to backward compatible backend
default_backend jve_https_old
I think this is because openssl s_client sends v3.1 (TLSv1.0) for the
initial Client Hello :
https://www.openssl.org/news/changelog.html#x17
You can verify with a network capture.
Maybe you can also try with "curl --tlsv1.2" which should use a 3.3
version.
That's a very interesting details. Indeed curl sets the HELLO version to
0x0303
whereas OpenSSL uses 0x0301. Interestingly, both Firefox and Chrome also
use 0x0301
in the version of the record layer. In all cases though, the version of
the handshake
message is correctly set to 0x0303, as you would expect for TLS1.2.
$ openssl s_client -connect jve.linuxwall.info:443 -tls1_2 -servername
jve.linuxwall.info -debug|head
CONNECTED(00000003)
write to 0x97a510 [0x984043] (342 bytes => 342 (0x156))
0000 - 16 03 01 01 51 01 00 01-4d 03 03 22 95 43 27 f9
....Q...M..".C'.
^^^^^ ^^^^^^
record layer version handshake version
I would argue that HAProxy is doing the wrong thing here: the
req_ssl_ver variable
should return the handshake version, not the record layer version.
- Julien
