Supported cipher-suites on the ESP8266
Posted: Mon Dec 21, 2020 12:38 am
The latest updates to certbot from Let's Encrypt have presented a problem for my micropython-powered esp8266 due to the incompatibility of cipher suites, which now supports the recommended set listed here: https://wiki.mozilla.org/Security/Serve ... default.29
After my server update, I noticed that my device was no longer connected. Looking at my logging, I saw many reconnection attempts all terminating in "ssl_handshake_status:-40".
Looking at the forums, I found this post https://github.com/micropython/micropython/issues/3198 which looks very similar to my issue (for someone connecting to the telegram API).
From my reading of this, it seems like the core TLS library (axtls) only supports these cipher suites:
To resolve my issue, I had a few attempts:
1. I investigated using something other axtls (e.g. https://github.com/micropython/micropython/issues/3198) but that solution is only partially formed, and completing it is a little outside of my wheelhouse.
2. It's possible to just add these denounced cipher suites to the let's encrypt configuration. I'd be willing to do this for my toy IoT device, but issue is that I have other sites on my server that would be impacted, and I don't feel great about that.
3. Removing the SSL connection from my IoT device to my server.
Ultimately I went with option 3, reluctantly.
I hope I've summarised the situation correctly, and if so, the ESP8266 micropython port cannot connect to servers using the default Let's Encrypt certificates.
I appreciate all the work that people do here, and understand there are many conflicting interests/priorities, but my hopes for this post are:
1. Someone can point out why I'm wrong, and present an option I didn't see
2. This bumps up the priority for implementing a more fully featured TLS library
3. It helps someone else understand why they're seeing ssl_handshake_status:-40
4. It informs someone of the limitations of using this setup before they invest.
After my server update, I noticed that my device was no longer connected. Looking at my logging, I saw many reconnection attempts all terminating in "ssl_handshake_status:-40".
Looking at the forums, I found this post https://github.com/micropython/micropython/issues/3198 which looks very similar to my issue (for someone connecting to the telegram API).
From my reading of this, it seems like the core TLS library (axtls) only supports these cipher suites:
- AES128-SHA
AES256-SHA
AES128-SHA256
AES256-SHA256
To resolve my issue, I had a few attempts:
1. I investigated using something other axtls (e.g. https://github.com/micropython/micropython/issues/3198) but that solution is only partially formed, and completing it is a little outside of my wheelhouse.
2. It's possible to just add these denounced cipher suites to the let's encrypt configuration. I'd be willing to do this for my toy IoT device, but issue is that I have other sites on my server that would be impacted, and I don't feel great about that.
3. Removing the SSL connection from my IoT device to my server.
Ultimately I went with option 3, reluctantly.
I hope I've summarised the situation correctly, and if so, the ESP8266 micropython port cannot connect to servers using the default Let's Encrypt certificates.
I appreciate all the work that people do here, and understand there are many conflicting interests/priorities, but my hopes for this post are:
1. Someone can point out why I'm wrong, and present an option I didn't see
2. This bumps up the priority for implementing a more fully featured TLS library
3. It helps someone else understand why they're seeing ssl_handshake_status:-40
4. It informs someone of the limitations of using this setup before they invest.