ESP32 Forum

Hello!

I'm working on a project using mbedTLS in server mode (MBEDTLS_SSL_IS_SERVER).

I found this example from the official github repo:
https://github.com/ARMmbed/mbedtls/blob ... d_server.c

and I'm adapting it for esp-idf... at the moment to keep it simple I'm not working with threads (1 connection served at a time).
I'm using a certificate signed by our company's internal CA, that is "trusted" by all our browsers.

I'm facing some problems during the handshake phase: sometimes it fails with EOF error, sometimes it works but then the browser closes the connection without sending data... the result is that everything is much slower than the same example without SSL (plain http with lwip).

Does anyone worked with mbedTLS in server mode? I see that in esp-idf the example provided is using OpenSSL instead... is it better?
Thanks!

I see that in esp-idf the example provided is using OpenSSL instead... is it better?

Its just a wrapper around mbedTLS, so probably not. I've had issues with the SSL handshake when the connection was in non-blocking mode, is that the case?
I've since switched to BearSSL because I prefer the architecture and it uses less memory, buts its still classified as alpha.

Hi and thanks for your reply!

At the moment I'm working in blocking mode... I also sent a message to mbedTLS support forum with the full trace:
https://tls.mbed.org/discussions/generi ... erver-mode

Did you ever get a resolution to this puzzle. I too have ended up at exactly the same place as you have using exactly the same mbedTLS sample application. I am at a loss to explain.

Here is the ESP32 app I am using...

https://pastebin.com/rRBsd9wx

The symptoms are as you described. Premature EOF following a successful SSL handshake. I perform accept() to receive an in comming connection request, execute a handshake on it which succeeds and then attempt to read from the buffer but get a 0 for number of bytes returned and an underlying error code (with mbedTLS debug turned on) of -0x7280.

BearSSL has since transitioned from Alpha to Beta, so I think its safe to give it a try. You can get some hints on how to use it from my Alexa implementation (start here: https://github.com/MrBuddyCasino/ESP32_ ... e_socket.c).

Howdy @BuddyCassino

Oh my ... another SSL implementation.

My thinking is that ESP-IDF supplies mbedTLS as a core TLS/SSL provider. The ESP-IDF then provides an OpenSSL API wrapper ... which I guess is because OpenSSL is a very popular API. If I understand correctly, BearSSL is yet *another* SSL implementation that doesn't relate to either mbedTLS or OpenSSL. What would my thinking be to try and leverage a different SSL implementation other than mbedTLS or the OpenSSL wrapper API? I want to have as few external dependencies as possible which would seem to make me think that I would want to use mbedTLS (the ESP-IDF supplied TLS/SSL implementation) or the OpenSSL API on top of mbedTLS. What would be a motivation to start delving into BearSSL?

Neil

You're absolutely right, bringing in a new dependency should be the last resort. But if all else fails, it may be better than trying to bang your head against the wall for weeks. The OpenSSL API is horrible btw., but because it was the only OSS TLS lib its usage is widespread. Why supporting it would be an advantage on a MCU I don't know, to be honest.

In my case, I had no choice because I was running out of memory and BearSSL is more efficient. Also it works really nice with async I/O.

I created an issue on Github relating to the puzzle I was having with mbedTLS ... the link is here:

https://github.com/espressif/esp-idf/issues/1009

I am delighted to report that there were some awesome suggestions on what the cause may have been and they were bang on. In summary, it appears that the mbedTLS APIs I was using were working just fine but my understanding of how to build "correct" certificates for use in an mbedTLS server were not even close. With that clue in mind, I was able to google around and stackoverflow came to my aid (yet again).

For my testing, I was using Chrome as the source of the SSL transport and had expected to see a "GET / ..." as the data arriving. While the SSL handshake "appears" to have been "mostly" successful, the the SSL client side in Chrome was flagging "possible problems" and terminating the connections (EOF). As a circumvention, one can run Chrome with the "--ignore-certificate-errors" for testing. At this point, all was working well. With this in mind, I can now start studying "what it takes" to create a "good enough" self signed certificate. The story seems to be able to be found here:

https://stackoverflow.com/questions/101 ... 6#27931596

and I now need to read, read and re-read to make to comprehend properly.

---

Thanks again for the pointer to BearSSL ... I'll most definitely have a read of the docs on it. Perhaps you could write up a recipe or blog on your experiences? Maybe a sample SSL client and a sample SSL server?

Guess I should, but I've got no energy currently due to an annoying project (anybody else hates Scala?).