HTTP Support and HTTPS Certificates

[itopaloglu83]

Hello,

I remember the alpha release video mentioning something about how there is a problem with HTTP connections. According to some WiFiClientSecure library documentation I could find setInsecure() method disables the SSL certificate verification but keeps the connection as https. It looks like WiFiClient can be used for HTTP-only connections.

https://arduino-pico.readthedocs.io/en/latest/bearssl-client-secure-class.html#setinsecure
https://github.com/espressif/arduino-esp32/blob/master/libraries/NetworkClientSecure/src/WiFiClientSecure.h#L2

It might be just me but I cannot find decent documentation for espressif libraries. After digging through some of the source code I believe something like below might be achievable.

#ifdef USE_HTTP
  WiFiClient *client = new WiFiClient;
#else
  WiFiClientSecure *client = new WiFiClientSecure;
  client->setInsecure();
#endif

P.S.: As a side note, it might be a good idea to either implement HTTPS certificate verification or embed the current certificate signature to prevent MITM attacks.

[ryanckulp]

great find @itopaloglu83 ! i much prefer setting USE_HTTP=true versus dropping *client in 3-4 places (alpha release video).

cc @GoReNeY this would be a nice improvement for BYOS > local network users.

[Conor-Behard333]

Context: I've been looking at getting a TRMNL device for home usage to show to-do lists and even have a visual monitoring display of the services I self host in my homelab.

To add on to what @itopaloglu83 was saying in their side note, currently no support for https is what is stopping me from going for a BYOS setup of TRMNL for home usage (and potentially at work too).

My intentions would be to host the server on a local Kubernetes cluster. The device would then communicate to the server over HTTPS with a custom cert (would also need support for custom/self-signed certificates).

Not sure on what the complexities of having this be implemented would be, but it would definitely be something that I see as important for the DIY users of TRMNL as HTTPS is a basic requirement for secure home labs.

[itopaloglu83]

@Conor-Behard333 the TRMNL is in fact using HTTPS at the moment but not validating the certificate. So in practice, you can use any certificate you'd like and it would continue to work without issues. My side note was about the fact that the https certificates are not being validated which can be a security concern. Though certificate validation brings a lot of overhead in processing and power consumption.

There's also another function called setCACert(const char *rootCA) which allows you to set a root certificate authority (CA) signature so that the library only trusts certificates signed by that particular root CA.

[Conor-Behard333]

Ah right I see what you mean now. Interesting to know that cert validation can cause overhead in the power consumption side of things. Would definitely be useful to have the setCACert function.

[samrocketman]

Adding on to this I manage my own certificate authority. I prefer to secure my home automation network with mTLS authentication and verification.

Are there plans to support mTLS or installing the firmware with custom CA certificates? Should I file a separate GitHub issue as a feature request if not?

Edit: #54 (comment) answers one of my questions. It would be nice for the firmware to support this; maybe I will open a pull request.

I bought TRMNL today 🎉

[vincecitizennet]

Adding a CA into the firmware adds a lot of other complexities that need to be addressed.

• A single CA would lock the device to that single issuer
• Adding multiple CAs solves that, but takes up more space and requires more maintenance
• Current firmware would stop working altogether in 2035, requiring a (relatively) difficult update unless an insecure fallback option is added (mdns?)

For me, a big advantage of a device like this is being able to operate indefinitely without external support, which is hard to balance with proper security.

[stevekennedyuk]

On Tue, 4 Feb 2025 at 19:01, Vincent Busam ***@***.***> wrote: Adding a CA into the firmware adds a lot of other complexities that need to be addressed. - A single CA would lock the device to that single issuer - Adding multiple CAs solves that, but takes up more space and requires more maintenance - Current firmware would stop working altogether in 2035, requiring a (relatively) difficult update unless an insecure fallback option is added (mdns?) For me, a big advantage of a device like this is being able to operate indefinitely without external support, which is hard to balance with proper security.

In the EU they are starting to mandate security in devices, especially ones that can connect to the Internet so they can't be used for botnets etc. Steve

…

-- NetTek Ltd UK mob +44 7775 755503 UK +44 20 3432 3735 / US +1 (650) 423 1390 social id stevekennedyuk Euro Tech News Blog http://eurotechnews. <http://eurotechnews.blogspot.com> net

[vincecitizennet]

Or maybe an advanced option in the captive portal setup page to set a custom CA and API URL?

[Conor-Behard333]

In my work (in the UK) we have very strict security guidelines and if I wanted to set TRMNL up for say basic monitoring or a todo list communicating with an on-prem server, it would fail a security review due to not verifying certs.

Even implementing custom CA support as an optional feature would be enough for majority of user.

But I do understand the complexities of implementing it is a lot easier said than done.

[itopaloglu83]

When I check Keychain Access I see that there are over 100 root certificates trusted by macOS. I don't think something like that would be possible for the firmware.

From what I understand from the firmware, the device talks to terminal servers first, which gives it a signed s3 bucket url where the bitmap images reside. As a first step the terminal server certificates can be pinned. And most likely that would be enough.

At some point the device will connect to arbitrary URLs with would require continuous root certificate updates and there are even certificate blacklists for stolen and compromised things.

[itopaloglu83]

Just a clarification, I think the firmware should only pin the terminal certificates first. It is rather complicated to create an IoT device that connects to arbitrary URLs and have the correct root certificates for them. I cannot even boot up and open google with some old phones.

[samrocketman]

I agree with @itopaloglu83 latest comment. In my case, I might even develop an intermediate service which generates the raw BMP and the device is setup with certificates to authenticate and get the image rather than the device generating BMP (If I’m incorrect on how it works today let me know).

I am thinking of modifying the firmware so that its only function is to download a BMP and refresh the screen rather than process JSON to generate a BMP.

[itopaloglu83]

@samrocketman the api response contains the URL which the bitmap image will be downloaded.

curl https://usetrmnl.com/api/display --header "Access-Token:<<YOUR TOKEN HERE>>"

When the device is not in sleep mode, the image_url gives you a signed s3 bucket url.

{
  "status": 0,
  "image_url": "https://usetrmnl.com/images/setup/sleep.bmp",
  "filename": "sleep",
  "refresh_rate": 29527,
  "reset_firmware": false,
  "update_firmware": true,
  "firmware_url": "https://trmnl.s3.us-east-2.amazonaws.com/FW1.4.5.bin",
  "special_function": "identify"
}