ammar

In my post about esp-visualize I declared my intention to “query my tasks list from my caldav server and display different types of messages that act as a reminder” using my esp32-s3 board.

Well, this seems to be harder than I thought it would be, if you have the energy and the time, dive with me into one of the problems.

So let’s start the story from the beginning.

I had a wifi module working, it connects to my network and gets an ip address from dhcp, and it can send an HTTP request to some random website successfully, hooray!

I change the url to be my caldav’s server (It’s a radicale instance behind a traefik reverse proxy), and voila… nothing happens.

After accidentally realizing that I can log panic information in rust in the `#[panic_handler]` (duh!), I see it’s a handshake failure, not sure if I felt frustrated or excited, I need to ask my therapist about this!

My first assumption was a certificate issue, so I looked up the documentation of the crate I’m using (reqwless) and I found that the code I copied from the book already disables certificate verification (note to future self, spend few more minutes understanding the config you copy from tutorials).

I also found that reqwless is using `embedded-tls` which only supports tls1.3 (It can be made to use `esp-mbedtls` which supports tls1.2 and tls1.3 but I didn’t try that yet).

My next assumption is that my traefik instance doesn’t support tls1.3, life would have been simple if that was the case but a simple openssl command proved me wrong

openssl s_client -connect <domain>:443 -tls1_3

As we see, life isn’t fair, and now I have to figure out how do packet capture to get more information, urghh.

My router runs openwrt, so I looked up how to do packet capture and found this pretty cool guide.

So what was the situation? A client hello packet followed by a tls alert, the alert is handshake failure (40), no certificate exchange so that confirms it is not a certificate verification issue, so why the server didn’t like my client hello?

Luckily openssl has the option `-trace` which shows exchanged packets so I can compare them, and here is what we found!

First, the low hanging fruit, the cipher suites, my esp32 was sending a single one(TLSAES128GCMSHA256) so adding `-ciphersuites TLSAES128GCMSHA256` option to the openssl command immediately ruled this out.

Next, “Extension: supported_groups”™ was different, my esp32 was sending a single value for secp256r1 and openssl was sending that plus other values.

Using the option `-groups secp256r1` reproduced the issue, this is great, I go to the Coop-cloud’s traefik recipe I use, and I modify it to support the supported group (https://git.coopcloud.tech/coop-cloud/traefik/pulls/73).

I use openssl to verify and now handshake works fine with `secp256r1` so I do another cargo run and guess what? It’s still a handshake failure!!

Okay, that was enough to take in for today I guess, I will stare at client hello packets and compare their bytes again on another day.