Add Rustls examples

[bjoernQ]

Submission Checklist 📝

• I have updated existing examples or added new ones (if applicable).
• I have used cargo xtask fmt-packages command to ensure that all changed code is formatted correctly.
• My changes were added to the CHANGELOG.md in the proper section.
• My changes are in accordance to the esp-rs API guidelines

Extra:

• I have read the CONTRIBUTING.md guide and followed its instructions.

Pull Request Details 📖

Description

This adds two examples using Rustls (a client and a server) for ESP32, ESP32-S3 and ESP32-C6.

Something I learnt just now is that currently it's impossible to compile Rustls for targets w/o atomics - I opened an issue in the Rustls repo for that. (i.e. it's the usage of alloc::sync::Arc in Rustls itself - seems like all the dependencies can be tweaked to use portable-atomic)

Given that, I'm not sure if these examples are something we currently want to have in the repo? I am also happy to extract the examples and the supporting code into its own repo in my personal GitHub space fow now otherwise

Testing

Running the examples on supported targets

[bjoernQ]

Fixes #1836

While Rustls will also work on H2 no examples are added for H2

[AnthonyGrondin]

Given that, I'm not sure if these examples are something we currently want to have in the repo? I am also happy to extract the examples and the supporting code into its own repo in my personal GitHub space fow now otherwise

TLS is the next major part after getting the HAL and drivers running. Many protocols and systems use/require it, especially in IoT development. Now the question lies down to; What is the roadmap?

Should esp-hal come with an "official" supported (maintained by the organization) TLS solution, using either rustls, embedded-tls, esp-mbedtls, etc. Or should there be an interface like ESP-TLS to ensure compatibility across multiple TLS providers and libraries. These are discussions pertaining to TLS in general and not specifically rustls.

All three of the above mentionned TLS suites support a different set of features, and compatibility. I believe both Rustls and embedded-tls to be the future of TLS on bare-metal, since they are more lightweight and pure Rust implementation. This should be documented for new users who come across needing to use TLS on bare-metal.

Rustls

• Pure rust implementation
• Requires alloc and atomics
• Supports TLS1.2 and TLS1.3
• Supports both client and server
• Supports mTLS
• Hardware acceleration possible (not currently implemented)

embedded-tls

• Pure rust implementation, for embedded systems
• Can work without alloc
• Only supports TLS 1.3
• Only supports client, doesn't support server yet.
• Supports client certificate authentication
• Hardware acceleration possible (not currently implemented)

esp-mbedtls

• C library used through Rust FFI
• Doesn't require alloc. Requires malloc(), calloc(), free() from esp-wifi
• Supports both TLS1.2 and TLS1.3
• Supports both client and server
• Supports mTLS
• Hardware acceleration possible (currently only using hardware RSA)

[AnthonyGrondin]

I can build both examples for esp32s3, but they need a custom partition table because they exceed the default 1MB partition size.

[bjoernQ]

I totally agree that TLS is an important topic

We don't have an official TLS roadmap ,yet - but I'd say both, Rustls and embedded-tls (both HW accelerated) is something I personally want.

After my vacation I'll look into lifting the atomics requirement for Rustls so it will work on all our targets

[MabezDev]

I've converted to draft until we can support all chips, hopefully it won't take too long to get upstream to allow using portable-atomic 🤞

[MabezDev]

Just taking another look at this, maybe we should merge this in it's current state? We know the upstream issue needs to be resolved for the non-atomic targets, but that doesn't mean we can't land support for the atomic's target now, I think?

[MabezDev]

Did you mean to close this, or are you planning on opening a new one?

[bjoernQ]

Did you mean to close this, or are you planning on opening a new one?

oh - that was a mistake