Config for old client (TLS 1.0 / 1.1) won't work, for (at least) HAProxy 2.4.

[lvergergsk]

https://ssl-config.mozilla.org/#server=haproxy&version=2.4&config=old&openssl=1.1.1k&guideline=5.7

Comparing intermediate config with old config, you removed no-tlsv10 no-tlsv11, but this actually does not allow TLS 1.0 and TLS 1.1. You will need to add ssl-min-ver TLSv1.0 for this to work.

You can try it use curl --tlsv1.0 --tls-max 1.0 ...

[gene1wood]

@lvergergsk When you use the config that you link to in HAProxy, does HAProxy throw an error (can you share what the error is if it does)?

Can you tell me more about the curl line you start? Are you saying that HAProxy accepts the configuration but something wrong can be seen when you run a curl command?

[lvergergsk]

@gene1wood There was no error log in haproxy and the error produced by the curl command is below:

curl --tlsv1.0 --tls-max 1.0 https://xxx.xxx.com/
curl: (35) OpenSSL/1.1.1t: error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version

To clearfy, the point I intend to make is following: Comparing the intermediate and old config, I think your old config is trying to allow TLS 1.0 and TLS 1.1 for those old client. On the other hand, the value of ssl-min-ver is default to TLSv1.2 as decribed in HAProxy doc. Hence we will fail to use TLS 1.0 and TLS 1.1 to connect the server with given old version of HAProxy config.

I added ssl-min-ver TLSv1.0 to my server and this fixed our old clients and my test curl command.

[lvergergsk]

Actually ssl-min-ver and ssl-max-ver is preferred over no-tlsv... option from HAProxy 2.x.

[janbrasna]

It was buggy before 2.2 https://github.com/haproxy/haproxy/commit/2e8d52f869ed7673a8274ec7b045161e09350251 see https://github.com/haproxy/haproxy/issues/595 — so the question is… if that gets changed to ssl-min/max-ver, should that be behind haproxy version conditional, or such bug in the server should not be polluting the config definition? (Thing is… if the configuration doesn't get picked up, is it safe to provide it as a recommendation?)

EDIT: Oh it's a v2.0+ feature only IIRC anyways, so it has to be defined behind a version check:/ similar to https://github.com/mozilla/ssl-config-generator/commit/342242c687861c94af9a2189961f16ffad1b9528 — so I'd make the split at v2.2 to render no-* flags vs. newer ssl-min* to also get rid of the warning #152

How much work should go into fixing old configs for newer daemon versions (that might change defaults and need explicit legacy flags added)?

[janbrasna]

@lvergergsk What you're suggesting to force-enable TLSv1.1-v1.2 is to change the configs (for 2.0+ or 2.2+ see above) along the lines:

    # intermediate configuration
-    ssl-default-bind-options prefer-client-ciphers no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
+    ssl-default-bind-options prefer-client-ciphers no-tls-tickets ssl-min-ver TLSv1.2
-    ssl-default-server-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
+    ssl-default-server-options no-tls-tickets ssl-min-ver TLSv1.2

(↑ this one has no impact, but needs v2+)

    # old configuration
-    ssl-default-bind-options no-sslv3 no-tls-tickets
+    ssl-default-bind-options no-tls-tickets ssl-min-ver TLSv1.0
-    ssl-default-server-options no-sslv3 no-tls-tickets
+    ssl-default-server-options no-tls-tickets ssl-min-ver TLSv1.0

to force lower TLS version than current default to cater to old clients?