What about SSL-support

[petricf]

It seems that https-support currently only works with an ESP8266.

What about extending the support for ESP32 ?

The other lib i found esp32_https_server is not as feature rich as this one.

After reading the source it seems that AsyncTCP is missing SSL support.

Reading AsyncTCP_SSL doc it could be a SSL-enabled version of AsyncTCP.
In the code there is a method beginSecure having the same signature.

Drawback: Does not compile with mbedtls from ESP32(-C6) board package (here: v. 3.3.8):
AsyncTCP_SSL/src/tcp_mbedtls.h:35:10: fatal error: mbedtls/net.h: No such file or directory

So it require more patching. Anyone willing to go into this direction.

[mathieucarbou]

What is your use case for having SSL on a web server on a MCU ?

[petricf]

1. Security
2. See how (well) it works

[mathieucarbou]

1. Security
2. See how (well) it works

This is not answering my question ;-)
What is your use case ? What will be the clients ? How they will connect ? Who will create the cert ? What is the certificate authority ?

[petricf]

Currently developing a Doorbell. Rings via an integrated (I2S) speaker. Can be connected to a SIP-Server to ring by phone additionally. Also capable to open the door during the call.
Communicates actually via http and WebSockets.

Due there are passwords (WLAN, SIP-Server) transferred an https-connection would be a good idea.

I am testing myself, others to come later.

Connected via WiFi. If supported i will be using a self signed cert at the test phase. Will be changeable later via Web Interface (maybe generated by a CA).

Any infos missing ?

[mathieucarbou]

The critical point is SSL Certificate validation.
Most users of the lib asking for SSL always have a use case involving browsers or uncontrolled clients and this is hardly possible to setup an SSL http web server on a MCU with a certificate that will be validated by a browser or any random client for 2 reasons: authority and domain. Most clients will reject a connection if the cert is self-signed or domain invalid.

The only use case where an SSL connection is valid is if you can completely control the client connecting to the async_ws server and have it either validate its certificate or blindly accept it.

That's why I often advise instead to use encrypted JWT tokens and/or encrypted API bodies for some specific calls. Even if the content of the data is not encrypted for all calls, it allows to keep the core and heap usage low (no ssl involved) and only encrypt/decrypt what's really sensitive.

async_ws supports middleware so this is not complicated to implement such mechanism, and probably more efficient on a MCU, although, I agree with you, ideally a complete SSL http server would be better.

SSL on a mcu requires a lof of processing, heap and flash memory, which could be used for more core tasks.

[petricf]

I agree with your reasoning. But if it don't get implemented can you be sure ?

As seen there are some other https projects like esp32_https_server i named in the intro or a beginning project like QuarkX. Maybe some implementation details can be taken from there.

The question also is why https seems to be supported for the (less powerful) ESP8266 and not for the ESP32.

Currently my app occupies about 1.3 MB code, 14% of the memory and nearly nothing of the LittleFS space.

JWT tokens are new to me. I will have look how they can help me out.

[mathieucarbou]

I agree with your reasoning. But if it don't get implemented can you be sure ?

Because of the experience in got on PsychicHTTPServer which is similar to this one and supports ssl because backed by esp-idf http server.

Users are complaining of high memory usage, bugs, have to use psram which is not so stable .
I know 2 users of psychic that had ssl requirement that are migrating to this library.
All depends for the memory on the board you will use of course but if you are limited to standard MCU then this does not leave a lot of memory and cpu space.

You can try psychic (which uses behind the scene http server).

‘if you do you need to use branch v2: i contributed a lot to this project back then and v2 supports the new espidf version.

[petricf]

Thanks for the hint. I will have a look to PsychicHttp also and come back with my impressions.