Fix TLS min/max for MBEDTLS 3.6.x

[kkalganov]

MBEDTLS supports TLS 1.3 since release 3.6.0, adopt the default values for internal variables accordingly.

[testclutch]

Analysis of PR #17048 at 42eb0a24:

Test ../../tests/http/test_17_ssl_use.py::TestSSLUse::test_17_07_ssl_ciphers[TLSv1.2-None-None-True-True] failed, which has NOT been flaky recently, so there could be a real issue in this PR.

Test ../../tests/http/test_17_ssl_use.py::TestSSLUse::test_17_07_ssl_ciphers[TLSv1.2-None-ciphers1251-True-True] failed, which has NOT been flaky recently, so there could be a real issue in this PR.

Test ../../tests/http/test_17_ssl_use.py::TestSSLUse::test_17_07_ssl_ciphers[TLSv1.2-None-ciphers1253-True-True] failed, which has NOT been flaky recently, so there could be a real issue in this PR.

Test ../../tests/http/test_17_ssl_use.py::TestSSLUse::test_17_07_ssl_ciphers[TLSv1.2-None-ciphers1254-True-True] failed, which has NOT been flaky recently, so there could be a real issue in this PR.

Test ../../tests/http/test_17_ssl_use.py::TestSSLUse::test_17_07_ssl_ciphers[TLSv1.2-ciphers1355-None-True-True] failed, which has NOT been flaky recently, so there could be a real issue in this PR.

Test ../../tests/http/test_17_ssl_use.py::TestSSLUse::test_17_07_ssl_ciphers[TLSv1.2-ciphers1356-ciphers1256-True-True] failed, which has NOT been flaky recently, so there could be a real issue in this PR.

Test ../../tests/http/test_17_ssl_use.py::TestSSLUse::test_17_07_ssl_ciphers[TLSv1.2-ciphers1358-ciphers1258-True-True] failed, which has NOT been flaky recently, so there could be a real issue in this PR.

There are more failures, but that's enough from Gha.

Generated by Testclutch

[vszakats]

CI consistently fails on some mbedTLS tests with this PR:
https://github.com/curl/curl/actions/runs/14440733778/job/40534479776?pr=17048

[kkalganov]

My understanding is that the tests fail as they still expect TLS 1.2, did I get it wrong?

[vszakats]

Suggested change

	#else
	/* mbedTLS 3.2.0 (2022) introduced new methods for setting TLS version */
	#if MBEDTLS_VERSION_NUMBER < 0x03060000
	mbedtls_ssl_protocol_version ver_min = MBEDTLS_SSL_VERSION_TLS1_2;
	mbedtls_ssl_protocol_version ver_max = MBEDTLS_SSL_VERSION_TLS1_2;
	#else
	mbedtls_ssl_protocol_version ver_min = MBEDTLS_SSL_VERSION_TLS1_3;
	mbedtls_ssl_protocol_version ver_max = MBEDTLS_SSL_VERSION_TLS1_3;
	#endif
	#endif
	/* mbedTLS 3.2.0 (2022) introduced new methods for setting TLS version */
	#elif MBEDTLS_VERSION_NUMBER < 0x03060000
	mbedtls_ssl_protocol_version ver_min = MBEDTLS_SSL_VERSION_TLS1_2;
	mbedtls_ssl_protocol_version ver_max = MBEDTLS_SSL_VERSION_TLS1_2;
	#else
	mbedtls_ssl_protocol_version ver_min = MBEDTLS_SSL_VERSION_TLS1_3;
	mbedtls_ssl_protocol_version ver_max = MBEDTLS_SSL_VERSION_TLS1_3;
	#endif

Flatten the #if tree?

Just wondering, wouldn't ver_min be MBEDTLS_SSL_VERSION_TLS1_2 for 3.6+, assuming that it still supports TLSv1.2?

[vszakats]

My understanding is that the tests fail as they still expect TLS 1.2, did I get it wrong?

I don't know what the issue/solution is here.

/cc @icing

[kkalganov]

I would imaging the PR would need to be picked by someone with insights into the automated tests involved. In the meanwhile it may help people struggling to make libcurl+mbedtls combo to work with TLS1.3.

[bagder]

It's not about the test case. Which is the minimum supported TLS version when using mbedTLS 3.6? I would presume it is 1.2.

[bagder]

Suggested change

	#if MBEDTLS_VERSION_NUMBER < 0x03060000
	mbedtls_ssl_protocol_version ver_min = MBEDTLS_SSL_VERSION_TLS1_2;
	mbedtls_ssl_protocol_version ver_max = MBEDTLS_SSL_VERSION_TLS1_2;
	#else
	mbedtls_ssl_protocol_version ver_min = MBEDTLS_SSL_VERSION_TLS1_3;
	mbedtls_ssl_protocol_version ver_max = MBEDTLS_SSL_VERSION_TLS1_3;
	#endif
	mbedtls_ssl_protocol_version ver_min = MBEDTLS_SSL_VERSION_TLS1_2;
	#if MBEDTLS_VERSION_NUMBER < 0x03060000
	mbedtls_ssl_protocol_version ver_max = MBEDTLS_SSL_VERSION_TLS1_2;
	#else
	mbedtls_ssl_protocol_version ver_max = MBEDTLS_SSL_VERSION_TLS1_3;
	#endif

[kkalganov]

Well, based on the code for 3.2 I assumed you wanted the most recent as default.
Anyway, I stumbled upon this while having MBEDTLS compiled with support for TLS 1.3 only. Also, I tried with ver_min set to 1.2 as you suggest, but got exactly the same error (curl error buffer: ssl_setup failed - mbedTLS: (-0x5E80) SSL - Invalid value in SSL config). Is it possible that curl tries to use ver_min first?

[bagder]

Is it possible that curl tries to use ver_min first?

Look at the code in that file. The ver_min and ver_max variables are used to set min and max accepted tls versions to mbedtls. It is then mbedtls that does the TLS negotiation.

If mbedTLS then somehow still does not negotiate the correct version it would to me seem to be to not be a curl issue. TLS 1.3 surely should not be the minimum accepted version by default.

[kkalganov]

Having support for the whole ver_min/ver_max span as the underlying library has is understandable, and Linux Distros and beyond are likely to ship mbedTLS with support for 1.2-1.3.

However, with such strategy, I wonder if setting explicit min/max is the way to go - why don't let the library to support what is does support? Wouldn't it be a more generic approach?

[bagder]

why don't let the library to support what is does support? Wouldn't it be a more generic approach?

Sure, that should work fine as long as the library is fine with it.