Okay, how bad can getting client HTTPS to work be really?

My chosen deployment method for the server part of my Swift-IoT-Hello project, a Digital Ocean App Server, ONLY does HTTPS connections. Meanwhile my client can only handle HTTP.

I could get around this a few ways. Many of them versions of:

• creating a local device gateway of some flavor
• configuring a more permissive external server (as the main or as a proxy)

Those types of solutions push the complexity into the project’s architecture in a way that might make it difficult for a student or beginner to spin up. IF I can get HTTPS working the complexity will feel more invisible, perhaps.

So that leaves trying spending at least some time to trying to get HTTPS to work.

For some chips HTTPS would be too much math and too much storage space, but the ESP32-C6 should be able to do it. At this stage, most things that can run Embedded Swift at all can probably do it.

So what does that look like? Here’s my initial todo list and some of resources I’ll need to get it done.

TODO:

• watch some videos
• do an esp-idf only https client example
• (optional) do a pico sdk only https example
• study SwiftNIO and it’s TLS library
• look at my existing (and other’s) Swift clients
• Look at some API packages / type-only packages
• choose a C framework
• go…

Watch Some Videos

For instruction and reference I prefer written articles, but for orienting myself to a space I like video.

Before creating an implementation I want refresh my memory / understand current best practices on the TLS handshake which distinguishes HTTPS from HTTP.

Here are some videos that help clarify the problems involved. The first one a lone is enough for the already conversant. It’s both specific to the exact topic and an overview. At the end is an “off-topic” but interesting discussion of Rust and Zephyr.

• The Linux Foundation
  • IoT TLS: Why It’s Hard - David Brown, Linaro (7 y.o.) Great great overview.
  • Zephyr TLS implementation uses mbed-tls
• Computerphile:
  • https://www.youtube.com/@Computerphile/search?query=TLS
  • Transport Layer Security (TLS) (5 y.o.)
  • TLS Handshake Explained (5 y.o.)
  • Ellip
  • Secret Key Exchange (Diffie-Hellman) (perhaps a bit extra, 7 y.o.)
  • Public Key Cryptography (perhaps a bit extra)
  • What are digital signatures (4 y.o.)
  • Key Exchange Problems
  • Elliptic Curves
  • SHA: Secure Hashing Algorithm (perhaps a bit extra)
  • Network Stacks and the Internet (if this isn’t familiar, 12 y.o.)
  • Secure Web Browsing (if this isn’t familiar, 9 y.o.)
  • What happens when you click a link? (most basic DNS/TCP/HTTP recap, 10 y.o.)
• Practical Networking
  • TLS 1.3
• Mongoose Networking Library
  • TLS for microcontrollers explained mostly a recap of tls in general until about 5:35
    • https://mongoose.ws
• Hitex
  • Hitex Webinar Secure communication for IoT devices with Mbed TLS (long, good overview but not example code)
• Misc Off Topic
  • https://ossna2025.sched.com/event/1zff7/why-rust-and-zephyr-are-a-good-fit-david-brown-linaro

A couple little text items to add because not a lot of decent video on it 1.2 vs 1.3:

• https://www.cloudflare.com/learning/ssl/why-use-tls-1.3/
• https://www.dchost.com/blog/en/updates-to-tls-1-3-standards-and-what-they-mean-for-your-servers/

Do a couple of hello worlds on the chips I’ll use

The espidf and the pico sdk both have https client examples that I’ll get rolling just to make sure there aren’t hardware/tool chain problems waiting to bite me.

• https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/protocols/esp_http_client.html
  • https://docs.espressif.com/projects/esp-idf/en/v5.2/esp32c6/api-reference/protocols/mbedtls.html
  • https://github.com/espressif/esp-idf/tree/v5.2/examples/protocols/https_mbedtls
  • (compare to rust) https://github.com/esp-rs/esp-mbedtls
• https://github.com/raspberrypi/pico-examples/tree/4c3a3dc0196dd426fddd709616d0da984e027bab/pico_w/wifi/tls_client

Study SwiftNIO

I’d like the API for my library to feel similar to how swift-nio-ssl works if the ergonomics are right for embedded. This assumes I’ll even get to that level of control for it. Which I probably won’t.

• https://github.com/apple/swift-nio-ssl
• https://github.com/apple/swift-nio/blob/main/Sources/NIOTLS/

NOTE: An example Swift based HTTP->HTTPS proxy exits in the SwiftNIO examples repo if I decide to fall back from this problem.

Look at my (and other’s) Swift HTTP clients

This might be a good moment to revisit the actual client ergonomics.

• https://github.com/carlynorama/APItizer (No dependencies, older)
• https://swiftonserver.com/building-swiftnio-clients/
• https://github.com/swift-server/async-http-client (async not available, but good to look at the ergonomics)
• https://swiftpackageindex.com/search?query=HTTP+client

Look at some API packages / type-only packages

Swift Log, Swift Metrics, Swift Distributed Tracing, Swift Configure all are API definition and/or types only packages. I’d like my client to work similarly. I should spend some time looking at how these get laid out and used.

Choose a base framework

So BoringSSL, which swift-nio-ssl uses, isn’t a great fit for embedded.

I’ve got to say that mbed-tls is winning just because I know that espressif, pico and zephyr all use it. If I push the implementation down low enough then it doesn’t matter as much what future implementers want to use. Here are some links, but I think I’m already pretty focused on mbed-tls.

• https://mbed-tls.readthedocs.io/en/latest/
  • https://github.com/Mbed-TLS/mbedtls
  • https://docs.espressif.com/projects/esp-idf/en/latest/esp32c6/api-reference/protocols/mbedtls.html
  • https://circuitlabs.net/https-with-tls-ssl-in-esp-idf/
• https://mongoose.ws/documentation/tutorials/tls/
• https://www.wolfssl.com

Summary

This is just an orientation post. In the next couple I’ll get the hello worlds working without Swift, as a base goal. If it’s easy… I’ll do more!