TLS: add SNI support for secure connections

[caiohamamura]

Probably fixes most TLS (https) issues #2970 #1707 #1484.

• This PR is for the dev branch rather than for the release branch.
• This PR is compliant with the other contributing guidelines as well (if not, please describe why).
• I have thoroughly tested my contribution.
• The code changes are reflected in the documentation at docs/*.

This will add SNI support for secure connections by providing these modifications:

• ssl_options: Add a char *hostname field
• espconn_secure_set_hostname: function to provides an interface to set the ssl_client_options.hostname .
• Within httpclient.c http_dns_callback function: before connecting through espconn_secure_connect it will set espconn_secure_set_hostname( hostname )
• During mbedtls_msg_config: it will now call mbedtls_ssl_set_hostname given ssl_client_options.hostname is provided, which will then address SNI.

[caiohamamura]

I just pushed commits for extending SNI support for MMQT and Websockets 4bf7acd

[marcelstoer]

Sorry, please rebase on dev - my bad.

[caiohamamura]

Rebase done!

[jmattsson]

This looks like a great addition!
Just one comment around some debug prints, but otherwise a big thumbs up from me 👍 (with the caveat I haven't looked at the 8266 branch in years 😅)

[jmattsson]

Thanks, looks safe then! 👍

…

On Sat, Aug 30, 2025 at 05:48, Caio Hamamura ***@***.***(mailto:On Sat, Aug 30, 2025 at 05:48, Caio Hamamura <<a href=)> wrote: @caiohamamura commented on this pull request. --------------------------------------------------------------- In [app/mbedtls/app/espconn_mbedtls.c](#3685 (comment)): > @@ -626,6 +626,20 @@ static bool mbedtls_msg_config(mbedtls_msg *msg) ret = mbedtls_ssl_setup(&msg->ssl, &msg->conf); lwIP_REQUIRE_NOERROR(ret, exit); + /* Add hostname for SNI support */ + if (ssl_client_options.hostname != NULL) { + os_printf("Configuring SNI for hostname: %s\n", ssl_client_options.hostname); So is it safe, or do you think I should remove some messages there? — Reply to this email directly, [view it on GitHub](#3685 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAGUJZ4DDQFEBQBPS2KNOVT3QCU7VAVCNFSM6AAAAACFBRUECGVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTCNRZHEZTCOJYGE). You are receiving this because you were mentioned.Message ID: ***@***.***>

[marcelstoer]

@caiohamamura This is gold, thank you!

I just went through a pile of old HTTPS issues (you linked to some of them) and tested the URLs we were testing back then. Just sending HTTP GET to them through our http module. The only ones that still don't work:

• https://dziadalnfpolx.cloudfront.net/
• https://clients5.google.com/pagead/drt/dn/
• https://raw.githubusercontent.com/espressif/esptool/master/MANIFEST.in

The output is always the same and I'm sure it's totally unrelated to what this PR fixes. Didn't investigate further, though.

HTTP client: Disconnected with error: -114
HTTP client: Connection timeout
HTTP request failed