Making an mbedtls-related fix available with recent esp-idf

[pptz]

The issue itself has been fixed here (although checking the return value can't hurt :) ), but I don't see a simple way to use this fix with esp-idf.

When updating from esp-idf v5.4.1 to esp-idf v5.4.2 or v5.5.1 my app's client PKI TLS session fails to connect after giving this warning: Jan 01 00:00:11.599 WARN do_mbedtls_handshake: session establish returned -0x5d80: 'SSL - Attempt to verify a certificate without an expected hostname. This is usually insecure. In TLS clients, when a client a'....

This happens because the mbedtls version was bumped up from 3.6.2 in 5.4.1 to 3.6.3 in 5.4.2 and 3.6.4 in 5.5.1, while the latest available libcoap release doesn't include the fix, although I believe the development tip does. The breaking change was introduced in 3.6.3:

[Default behavior changes] In TLS clients, if mbedtls_ssl_set_hostname() has not been called, mbedtls_ssl_handshake() now fails with MBEDTLS_ERR_SSL_CERTIFICATE_VERIFICATION_WITHOUT_HOSTNAME if certificate-based authentication of the server is attempted. This is because authenticating a server without knowing what name to expect is usually insecure. To restore the old behavior, either call mbedtls_ssl_set_hostname() with NULL as the hostname, or enable the new compile-time option MBEDTLS_SSL_CLI_ALLOW_WEAK_CERTIFICATE_VERIFICATION_WITHOUT_HOSTNAME.

Both enabling MBEDTLS_SSL_CLI_ALLOW_WEAK_CERTIFICATE_VERIFICATION_WITHOUT_HOSTNAME and inserting an mbedtls_ssl_set_hostname() call in the PKI branch (or using the fix from the develop branch) — fix the issue.

So I guess it's a question of making a new release available for esp-idf?

[mrdeep1]

@pptz Thanks for looking into and diagnosing this issue.

This was fixed in #1694 which is after #1570 which is the version which is in idf-extra-components. So yes, time to look at doing a new 4.3.5 release for idf-extra-components.

[pptz]

@pptz Thanks for looking into and diagnosing this issue.

This was fixed in #1694 which is after #1570 which is the version which is in idf-extra-components. So yes, time to look at doing a new 4.3.5 release for idf-extra-components.

Right, I realised this was fixed in develop only after posting.

It's kind of weird though: when I supply client_sni in the coap_dtls_pki_t setup_data, the session connects even when I populate it with garbage.

[mrdeep1]

It's kind of weird though: when I supply client_sni in the coap_dtls_pki_t setup_data, the session connects
even when I populate it with garbage.

It is up to the server what it does with the SNI - which is used for a server hosting multiple domains so that the correct domain certificate can be selected for doing the TLS session. If the server does not recognize the SNI information it can go with the default set of certificates.

[mrdeep1]

See espressif/idf-extra-components#627 where the fix for this has now been merged.