Feature request: secure WebSocket (wss)

Hello!

Congratulations for the great project.

I would like to know if you have intention to support secure WebSocket (use SSL over WebSocket) on the Microdot.

Thank you.

@miguelgrinberg Now that I was to stopping the test I observed that there is one more error, but is a same error happened some weeks ago and was fixed by you.

Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: [Errno 104] ECONNRESET

Complete log:

$ mpremote run echo_tls.py 
Starting sync server on 0.0.0.0:4443...
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: (-30976, 'MBEDTLS_ERR_SSL_BAD_HS_CLIENT_HELLO')
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: (-30592, 'MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE')
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: (-30592, 'MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE')
GET / 200
GET /echo 200
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: [Errno 104] ECONNRESET

EDIT: Just to know: will this error or any error (even already fixed by you in the past) follow the same idea, do not will be suppressed/fixed, just do not stop the Microdot and show that error on the log?

EDIT 2: My question above is important to me know if I need to report about a new/different errors or not. Like as this one, one more different error happened:

OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23

@beyonlo There are no strict rules. If the error(s) prevent something from working, then they need to be investigated. If the errors are just noise, but everything works, then it really depends. I can silence errors that are clearly not a problem (such as an EPIPE, which just means that the other side closed the socket). Non-standard errors with crazy error codes I feel less inclined to mess with, as these are often the result of specific drivers or libraries, and can mean different things under different stacks.

@miguelgrinberg

Report: 1. A strange behaviour (bug too?) 2. A bug

1. Strange Behaviour:

Since last week (on my first test of hello_tls.py) I would like to report you about a different behaviour in different platforms: ESP32 and Linux.

-- Using Microdot (over MicroPython) on Linux, when I open the Linux IP, the browser quickly showed the option that indicated that it was not secure, and an option to accept anyway, and proceed with unsecure HTTPS (self-signed). This same behaviour happen in all browsers that I tested, and always errors was showed, but there is no delay. Follow the log:

$ micropython 
MicroPython v1.19.1-299-gaf54d2ce9 on 2022-08-22; linux [GCC 11.2.0] version
Use Ctrl-D to exit, Ctrl-E for paste mode
>>> 
>>> 
>>> import hello_tls
Starting sync server on 0.0.0.0:4443...
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: (-30592, 'MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE')
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: (-30592, 'MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE')
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: (-30592, 'MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE')
GET / 200
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: (-30592, 'MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE')
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: (-30592, 'MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE')
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: (-30592, 'MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE')
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: (-30592, 'MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE')
GET /shutdown 200
>>>

-- Using Microdot on the ESP32, when I open the ESP32 IP, the browser stay processing for a long time (around 10 seconds, or more) until show the option to proceed with unsecure HTTPS. The same long time delay happen as well after that option already accepted, I mean, when I try to reopen the ESP32 IP. Is a long time to open the hello page. And, after opened, when I click in Click to shutdown the server that long time delay happen again, and just after that long time, the response The server is shutting down... is showed

-- This long time to reach ESP32 happen using Chromium, Edge and Safari (IOS) browsers, always showing errors on the log. Follow the log:

$ mpremote run hello_tls.py 
Starting sync server on 0.0.0.0:4443...
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: (-30592, 'MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE')
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: (-30592, 'MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE')
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: (-30592, 'MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE')
GET / 200
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: (-30592, 'MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE')
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: (-30592, 'MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE')
GET /shutdown 200

-- Some times, errors are very more intense (using chromium), and bigger delay, and ONE time was need to manually to stop the Microdot (CTRL+C) and start it again, because it was showing just the same error - not the normal errors. Follow the log:

$ mpremote run hello_tls.py 
Starting sync server on 0.0.0.0:4443...
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: (-30592, 'MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE')
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: (-30592, 'MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE')
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: (-30592, 'MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE')
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: (-30592, 'MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE')
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: (-30592, 'MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE')
GET / 200
GET /favicon.ico 404
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: (-30592, 'MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE')
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: (-30592, 'MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE')
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: (-30592, 'MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE')
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: (-30592, 'MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE')
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23

Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23

-- Using the Firefox to reach the ESP32 there is no error messages (better than running on Linux, that still has error messages), but still have a delay, but very less, around 1-2 seconds. Follow the log:

$ mpremote run hello_tls.py 
Starting sync server on 0.0.0.0:4443...
GET / 200
GET /favicon.ico 404
GET /shutdown 200

-- More tests was done using Microdot on ESP32 with hello_tls.py (using just Chromium), with sometimes different messages, just to report you. Follow the log:

$ mpremote run echo_tls.py 
Starting sync server on 0.0.0.0:4443...
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: (-30592, 'MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE')
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: (-30592, 'MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE')
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: (-30592, 'MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE')
GET / 200
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: (-30592, 'MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE')
GET /echo 200
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: [Errno 104] ECONNRESET
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: [Errno 104] ECONNRESET
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: (-30592, 'MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE')
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: (-30592, 'MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE')
GET / 200
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: (-30592, 'MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE')
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 45, in accept
OSError: 23

$ mpremote run hello_tls.py 
Starting sync server on 0.0.0.0:4443...
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: (-29312, 'MBEDTLS_ERR_SSL_CONN_EOF')
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: (-29312, 'MBEDTLS_ERR_SSL_CONN_EOF')
Traceback (most recent call last):
  File "microdot.py", line 914, in run
  File "microdot_ssl.py", line 46, in accept
OSError: (-29312, 'MBEDTLS_ERR_SSL_CONN_EOF')
GET / 200
GET /shutdown 200

2. The Bug:

-- While I was doing that tests above with hello_tls.py, when I tried to open the ESP32 IP, the Hello was showed and Microdot immediately stopped. This test was done with Firefox. Follow the log:

$ mpremote run hello_tls.py 
Starting sync server on 0.0.0.0:4443...
GET / 200
Traceback (most recent call last):
  File "<stdin>", line 36, in <module>
  File "microdot.py", line 923, in run
  File "microdot.py", line 32, in create_thread
  File "microdot.py", line 966, in handle_request
  File "microdot.py", line 485, in write
OSError: -104

@beyonlo So all these tests that you are doing are with a self-signed certificate that the browser does not accept? Have you tested a certificate that the browser is configured to accept/trust, which is the normal workflow? I haven't really tested self-signed certificates, they're just not very practical since all browsers reject them.

Hi @miguelgrinberg

@beyonlo So all these tests that you are doing are with a self-signed certificate

Yes, following the README.md how to create self-signed certificates - that is exactly what I need for my project, thank you!

that the browser does not accept?

I don't know if I understand this question part very well. After that browser detect that is a self-signed certificate, it show a option to Accept the Risk and Continue (screenshot below). So after that I click in the Accept the Risk and Continue button, and I do not need anymore accept the second time that I access this IP and this self-signed certificate. So, answering your question: the browser accept, but I need first click in Accept the Risk and Continue button.

Screenshot from 2022-09-12 15-30-53

Have you tested a certificate that the browser is configured to accept/trust, which is the normal workflow?

This means that is not self-signed certificate, but a certificate (mostly payed) that is generated and guaranteed by a entity, right? No, I do not have this kind of certificate! Anyway, what I need (and maybe many others) is just to use the self-signed certificates on the applications, where this applications will not be online on the internet, but mostly offline, but supporting secure connection (HTTPS and wss), even not connected to the internet, but just on local WLAN/LAN.

I haven't really tested self-signed certificates, they're just not very practical since all browsers reject them.

Sorry, I was thinking that you created the the README.md just to explain how to create a self-signed certificates to me and other people to test the TLS examples. So you do not used that for tests? Sorry, I'm a bit confuse.

@beyonlo self-signed certificates have become less practical, because browsers introduce all these barriers to use them. Chrome for example does not provide an option to access the site anymore when the certificate is self-signed.

I believe this was mentioned above, you can configure your browser to accept certificates from a certificate authority that is managed by yourself. This is closer to how official certificates work. The mkcert tool makes it easy to create them, and to configure browsers to accept them. My goal is to offer support for proper certificates. Self-signed certs is less interesting to me because they have no practical use outside if testing, and even that is not easy anymore with some browsers.

The examples in the README are okay to use when you use a client that is not a browser that you can configure to ignore validation. Most clients have an option for this. Browsers unfortunately are not a good case for self-signed certs. I think I'm going to update those instructions to use mkcert instead, because it was not my intention to suggest or recommend self-signed certs for any use other than quick tests between two scripts running a client and a server.

@beyonlo self-signed certificates have become less practical, because browsers introduce all these barriers to use them. Chrome for example does not provide an option to access the site anymore when the certificate is self-signed.

Understood. I tested that on the Chrome for Android and works. But I tested just Chrome for Android, not Chrome for PC. As my smartphone has a old version of Android, maybe this version of Chrome on Mobile still works.

I believe this was mentioned above, you can configure your browser to accept certificates from a certificate authority that is managed by yourself. This is closer to how official certificates work.

So sorry, I remember that, but I was thinking that is just about Accept the Risk and Continue. Now I understand better, thank you!

The mkcert tool makes it easy to create them, and to configure browsers to accept them. My goal is to offer support for proper certificates. Self-signed certs is less interesting to me because they have no practical use outside if testing, and even that is not easy anymore with some browsers.

Perfect! I wasn't know if that is possible - like as a official certificates!

The examples in the README are okay to use when you use a client that is not a browser that you can configure to ignore validation. Most clients have an option for this. Browsers unfortunately are not a good case for self-signed certs.

All right, understood!

I think I'm going to update those instructions to use mkcert instead, because it was not my intention to suggest or recommend self-signed certs for any use other than quick tests between two scripts running a client and a server.

I think that instructions for the mkcert on the README will be great, but maybe you can to have the both options on the instructions. For example, in the future I plan to have one application that will not have browsers to connect to Microdot HTTPS and wss, just clients applications, and in this case will works using a secure connection of SSL/TLS, because as you wrote: is possible to configure the clients (that is not a browser) to ignore the validation. Maybe more people can have the same scenario where do not need browsers as clients.

-- Using the Firefox to reach the ESP32 there is no error messages (better than running on Linux, that still has error messages), but still have a delay, but very less, around 1-2 seconds.

@beyonlo This delay is expected (at least what I've tested so far), TLS handshake takes approx 1 second in ESP32

-------------------------------------------------------------- benchmark 'device': 1 tests --------------------------------------------------------------
Name (time in ms)                                            Min         Max      Mean   StdDev    Median       IQR  Outliers     OPS  Rounds  Iterations
---------------------------------------------------------------------------------------------------------------------------------------------------------
test_dev[TLS Context Client Benchmark]:[sdev@esp32]     926.4680  1,067.2600  982.6270  74.5092  931.7590  136.1090       2;0  1.0177       5           1
---------------------------------------------------------------------------------------------------------------------------------------------------------

And for the requests

ESP32

Server Software:
Server Hostname:        espdev.local
Server Port:            4443
SSL/TLS Protocol:       TLSv1.2,ECDHE-ECDSA-AES256-GCM-SHA384,256,256
Server Temp Key:        ECDH P-384 384 bits
TLS Server Name:        espdev.local

Document Path:          /
Document Length:        306 bytes

Concurrency Level:      2
Time taken for tests:   6.197 seconds
Complete requests:      4
Failed requests:        0
Total transferred:      1484 bytes
HTML transferred:       1224 bytes
Requests per second:    0.65 [#/sec] (mean)
Time per request:       3098.607 [ms] (mean)
Time per request:       1549.303 [ms] (mean, across all concurrent requests)
Transfer rate:          0.23 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:     1371 2214 716.3   2743    2870
Processing:    26   29   2.6     30      33
Waiting:       15   18   3.9     18      23
Total:       1400 2243 716.4   2776    2897

Percentage of the requests served within a certain time (ms)
  50%   2776
  66%   2776
  75%   2897
  80%   2897
  90%   2897
  95%   2897
  98%   2897
  99%   2897
 100%   2897 (longest request)

UNIX

Server Software:
Server Hostname:        localhost
Server Port:            4443
SSL/TLS Protocol:       TLSv1.2,AES256-SHA256,4096,256
TLS Server Name:        localhost

Document Path:          /
Document Length:        306 bytes

Concurrency Level:      4
Time taken for tests:   2.784 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      37100 bytes
HTML transferred:       30600 bytes
Requests per second:    35.92 [#/sec] (mean)
Time per request:       111.366 [ms] (mean)
Time per request:       27.842 [ms] (mean, across all concurrent requests)
Transfer rate:          13.01 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       38  107  12.4    106     145
Processing:     0    1   0.7      1       6
Waiting:        0    0   0.2      0       1
Total:         38  108  12.3    107     146

Percentage of the requests served within a certain time (ms)
  50%    107
  66%    109
  75%    109
  80%    111
  90%    115
  95%    131
  98%    145
  99%    146
 100%    146 (longest request)

@beyonlo This delay is expected (at least what I've tested so far), TLS handshake takes approx 1 second in ESP32

@Carglglz So, if I use just HTTPS (with no wss), on the website (Microdot) running on the ESP32, will delay 1s for each click that I do right? Because as HTTP protocol is not a persistent connection, each click will be one more handshake, so will delay 1s - that is very bad. So in this case the better is always to use secure persistent WebSocket (wss) over HTTPS, so each click on the website will send/receive data over wss, that is persistent connections, and do not need to do a handshake every time. In this scenario will have just 1 handshake, when user open the website and connect to the wss. Is this thought correct?

So in this case the better is always to use secure persistent WebSocket (wss) over HTTPS, so each click on the website will send/receive data over wss, that is persistent connections, and do not need to do a handshake every time. In this scenario will have just 1 handshake, when user open the website and connect to the wss. Is this thought correct?

@beyonlo Yes, although there is a feature in TLS called session resumption (it is available in Python see rfc 5077 and SSLContext.wrap_socket), but unfortunately it hasn't been implemented yet in MicroPython and I'm not sure if it will be.

miguelgrinberg / microdot

Feature request: secure WebSocket (wss) #34