Hi Julien,
>> 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. Agreed. We really should ignore the record layer and use the client hello version instead (smp_fetch_ssl_hello_sni() has code checking for both if anyone has time to come up with a patch for req_ssl_ver). We had similar bugs in the past in those code paths (parsing SSL manually, see below). For this use case specifically most SSL libraries and browsers try to be most compatible, and since the record layer version doesn't impact the handshake in any way (other than some hanging SSL servers if the record layer is set to TLSv1.2), it is most often set to something low like SSLv3 (GnuTLS) or TLSv1.0 (OpenSSL), because the record layer simply doesn't matter. Also see: - rfc5246#appendix-E - http://marc.info/?l=haproxy&m=139710628814932&w=2 - commit 57d229747 ("BUG/MINOR: acl: req_ssl_sni fails with SSLv3 record version") Regards, Lukas
