Add Rustls provider including 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.

It is impossible to compile Rustls for targets w/o atomics - there is an issue opened and there were several attempts to tackle it. Currently it looks like they might accept a PR to make forks replacing Arc easy and maintainable (i.e. we will need a fork for now) - they are considering to make the core Arc free and we could build upon that (but that won't happen too soon for sure)

Please note: While this seems to work fine it's just the beginning. But we need to start somewhere.

This needs to support async and long-term we want this to support HW-acceleration

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

[bjoernQ]

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?

I remove the blocked label and mark this as RfR

[MabezDev]

Thanks for looking into this again!

[MabezDev]

Could we remove this and break it out into issues instead? I think we'll need a new label for the esp-rustls-provider package.

My fear is that we'll never check this again :D, if we have it in separate issues we can at least be aware.

[MabezDev]

We can create the issues after the PR is merged of course, there is no rush to do it now.

[bjoernQ]

I removed the TODOs here - we shouldn't forget about creating separate issues after the merge (since creating them before is kind of weird?)

[bugadani]

I love the name

[bjoernQ]

Me too 😄

[bugadani]

I only have micronits to pick right now - like the fact that this PR isn't about the examples I think, but the provider crate 🤔 What are the long term plans, are we to provide hardware acceleration through the provider crate, where we can?

[bjoernQ]

I only have micronits to pick right now - like the fact that this PR isn't about the examples I think, but the provider crate 🤔 What are the long term plans, are we to provide hardware acceleration through the provider crate, where we can?

Good point about the PR title 👍

Yes - we definitely want to support HW-crypto long-term (it's hidden in a vague sentence in the README - should have written it in the PR description)

[MabezDev]

Thanks for addressing my comments, LGTM.

Please don't forget to file the relevant issues once this is merged 😃