HELP WANTED - The web app cannot yet use SSL

[connornishijima]

Note: Some of the info below is out of date, the most recent comment contains updated information about the state of SSL support

Emotiscope uses the PsychicHTTP Arduino library. It's a swiss army knife that handles a whole HTTP server, websockets server, and more.

However, I haven't figured out its coolest feature: HTTPS/SSL.

Like, I know how I'm supposed to implement it, and have a server cert and key, but it just doesn't work.

A potential reason it doesn't work is the madness going on with my platformio.ini. For the sake of the I2S microphone and the new RMT LED driver, I needed an Arduino framework in PlatformIO that used ESP-IDF 5.x. The Arduino for ESP32 3.0.0-beta uses IDF 5.x, so Emotiscope was built on that. But because that IDF port is in beta, maybe the SSL/encryption side of the PsychicHTTP library isn't happy about that.

So currently, the SSL-enabled "app.emotiscope.rocks" page redirects you to a plain HTTP webserver running on your Emotiscope, since you can't send websockets commands from an HTTPS page to an unsecured one.

Honestly though, PsychicHTTP is now the only thing left in the system that explicitly requires an Arduino framework. Here's an idea:

Some time down the road, I want to port Emotiscope to ESP-IDF (No PlatformIO) and use only the IDF to enable an encrypted wss:// connection between the HTML page @ app.emotiscope.rocks and Emotiscope. That way, Emotiscope doesn't spend CPU cycles hosting an entire webserver off of itself while it runs, the code for the Emotiscope web-app is already open-source right now, it would just be hosted online instead, or by yourself remotely.

OR...

If I can get SSL working on PsychicHTTP I can skip all of that entirely and still host the web app from Emotiscope itself.

Questions For You:

• Could Emotiscope keep only the public key for a WSS:// connection? SSL isn't my strong suit.
• If not, how would I even store the private SSL key into the ESP32-S3/this repository in a way that doesn't expose it, defeating the purpose of a private key?
• If the key isn't hosted in the repo, how would DIY builds get connected?
• Don't keys expire? How on earth would I embed one anyways if that's the case?

[connornishijima]

Note: the upcoming Emotiscope 2.0.0 Multiplayer Update drops the PsychicHTTP library altogether, using the bare ESP-IDF framework instead of Arduino. wss:// may now be working, but I haven't tried it yet.

I'm still very confused on how to include HTTPS keys in a product without exposing them, or wondering why I'd care if I exposed them anyways in this instance where a client-side app is making a local TCP connection to a fellow device inside your WiFi network with your consent. Any man-in-the-middle attacker would have to already be connected to your home WiFi network to manipulate your Emotiscope to do... what? Change the brightness?

[earwin]

You can't run an HTTPS server without keeping a private key somewhere on it. The common approach to appliance-type devices is that you run self-signed certs either generated directly on-device or flashed to it. Each device has its own, so potential leak is not much of an issue. Downside is that since the cert has no approved root, the browser will loudly complain the first time you connect: "are you sure boss? ARE YOU ABSOLUTELY SURE?" but that's about it. Keys expire. You can set the expiration date to year 21xx, which will make the Emotiscope less heirloom-worthy, but would solve this short-term.