Toit
#server_tls.toit examples throws exception when client connects
Thread channel in help
DaveOBrien 11/12/2022 11:52 AM
Hi, Firstly I love the concept and vision you have shared for Toit. I've been experimenting and have been able to get jaguar installed and had success getting the basic 'hello world' example running as well as reading an analog input.
However I've run into a problem when I try to run the pkg-http/examples/server_tls.toit example as https-server.
I install the package with:
and install the container:
then:
I browse to 192.168.23.115:8080 and get the following output / error:
The link indicates the error is:
Any guidance appreciated. For refererence SDK is v2.0.0-alpha.37 and hardware is ESP32-DevKit4-VE(edited)
However I've run into a problem when I try to run the pkg-http/examples/server_tls.toit example as https-server.
I install the package with:
jag pkg install httpand install the container:
jag container install https-server server_tlsthen:
jag monitorI browse to 192.168.23.115:8080 and get the following output / error:
...
[jaguar] INFO: container 'https-server' started
[wifi] DEBUG: connecting
[wifi] DEBUG: connected
[wifi] INFO: network address dynamically assigned through dhcp {ip: 192.168.23.115}
[jaguar] INFO: running Jaguar device 'quirky-town' (id: 'd77b0961-5681-401d-abec-12dbffa9f161') on 'http://192.168.23.115:9000'
DEBUG: client connected {peer: 192.168.23.7:30191}
DEBUG: client disconnected {peer: 192.168.23.7:30191, reason: Mbedtls high level error 0x7080 - see https://gist.github.com/erikcorry/b25bdcacf3e0086f8a2afb688420678e}The link indicates the error is:
0x7080 SSL - The requested feature is not availableAny guidance appreciated. For refererence SDK is v2.0.0-alpha.37 and hardware is ESP32-DevKit4-VE(edited)
floitsch 11/12/2022 11:52 AM@erikcorry . Any idea?
erikcorry_arbat 11/14/2022 09:09 PM
Are you running the server on the device and connecting from your host workstation, or are both running on the device?
DaveOBrien 11/14/2022 11:00 PM
I'm running the server on the device (eg 192.168.23.115:8080) and connecting from my win10 host machine (eg 192.168.23.7) via chrome browser.(edited)
erikcorry_arbat 11/15/2022 08:24 AM
Are you using Jaguar? If so, so you see the little web page Jaguar serves up on http://192.168.23.115/ ?
erikcorry_arbat 11/15/2022 08:26 AM
Ah, I think that perhaps you are connecting with HTTP from Chrome, but the server is set up to use TLS (HTTPS).
erikcorry_arbat 11/15/2022 08:26 AM
The error message is pretty confusing, but it's just the TLS stack trying to make sense of the unencrypted HTTP connection that Chrome starts.
erikcorry_arbat 11/15/2022 08:28 AM
If you connect to https://192.168.23.115:8080/ you should get the 'correct' result.
Unfortunately the correct result is that Chrome will complain about the self-signed certificate, which is for "localhost", and not "192.168...", and which doesn't verify because it is not signed by one of the roots that Chrome has.
Unfortunately the correct result is that Chrome will complain about the self-signed certificate, which is for "localhost", and not "192.168...", and which doesn't verify because it is not signed by one of the roots that Chrome has.
erikcorry_arbat 11/15/2022 08:28 AM
To get this to work you would need a real certificate from eg LetsEncrypt.
DaveOBrien 11/16/2022 01:08 PM
Yes. I'm using Jaguar. I can see the page loaded at http://192.168.23.115:9000
I tried browsing to https://192.168.23.115:8080/ and get the same error
I tried both Chrome and Firefox(edited)
I tried browsing to https://192.168.23.115:8080/ and get the same error
DEBUG: client disconnected {peer: 192.168.23.7:58268, reason: Mbedtls high level error 0x7080 - see https://gist.github.com/erikcorry/b25bdcacf3e0086f8a2afb688420678e}I tried both Chrome and Firefox(edited)
floitsch 11/16/2022 01:14 PM
Could you maybe try to run the same program locally? Just to see if it works there?
floitsch 11/16/2022 01:14 PM
(while we wait for Erik)
DaveOBrien 11/16/2022 01:14 PM
Sorry, what do you mean by locally?
floitsch 11/16/2022 01:15 PM
jag run -d host $path_to_entry_pointfloitsch 11/16/2022 01:15 PM
This will start the program on your desktop machine
floitsch 11/16/2022 01:15 PM
Obviously, this won't work if you try to access gpio pins or so.
DaveOBrien 11/16/2022 01:18 PM
I haven't run on the host before, is there any setup to run.
floitsch 11/16/2022 01:18 PM
As long as you have
jagfloitsch 11/16/2022 01:18 PM
You can try with a simple hello_world.toit example first if you want to.
floitsch 11/16/2022 01:18 PM
It's just an easy way to use Toit on the desktop.
erikcorry 11/16/2022 01:18 PM
I tried running on the host and it works as expected.
erikcorry 11/16/2022 01:19 PM
I'm running origin/main of the pkg-http from github.
floitsch 11/16/2022 01:19 PM
Edit: oops. got messages mixed up.
So when that runs you can access https://localhost:8080 ?(edited)
So when that runs you can access https://localhost:8080 ?(edited)
DaveOBrien 11/16/2022 01:20 PM
So hello world runs on host.
DaveOBrien 11/16/2022 01:21 PM
the https-server doesn't but I haven't installed the pkg-http yet(edited)
floitsch 11/16/2022 01:21 PM
How did you build the https server in the program that is running on your ESP32?
floitsch 11/16/2022 01:22 PM
nevermind. Just reread the first message.
erikcorry 11/16/2022 01:26 PM
I'm seeing the same now. On the host the server_tls.toit runs and Chorme tries to connect (and gives the expected bad certificate error). On the device I get the 7080 message.
floitsch 11/16/2022 01:27 PM
Can you show us the command line you used to run locally (where it has the bad certificate error).
floitsch 11/16/2022 01:27 PM
And then the command line you used to install on the ESP32.
floitsch 11/16/2022 01:27 PM
(In the meantime I'm trying to reproduce on my own ESP32)
DaveOBrien 11/16/2022 01:28 PM
How do I install the pkg-http on the host?
floitsch 11/16/2022 01:28 PM
no need.
floitsch 11/16/2022 01:28 PM
I can reproduce.
DaveOBrien 11/16/2022 01:28 PM
okay
floitsch 11/16/2022 01:30 PM
I think this is the reason:
# CONFIG_ESP_TLS_SERVER is not setfloitsch 11/16/2022 01:30 PM
We recently modified our build-process and seem to have inadvertently changed this configuration option in the sdkconfig.
floitsch 11/16/2022 01:31 PM
that said. This is the ESP server. We might actually not need that.
Let me investigate.
Let me investigate.
floitsch 11/16/2022 01:32 PM
This looks more relevant:
# CONFIG_MBEDTLS_TLS_SERVER_AND_CLIENT is not set
# CONFIG_MBEDTLS_TLS_SERVER_ONLY is not set
CONFIG_MBEDTLS_TLS_CLIENT_ONLY=yerikcorry 11/16/2022 01:32 PM
I'm wondering what the use case is for running an HTTPS server on a device.
SInce the certificate issues are pretty bad when using a browser.
SInce the certificate issues are pretty bad when using a browser.
DaveOBrien 11/16/2022 01:36 PM
The use case is for an embedded device that generally doesn't have internet access. The user accesses the device management web app after connecting to the ESP32 running in AP mode. The web app provides current machine state and ability to change configuration.
floitsch 11/16/2022 01:37 PM
And since you are in AP mode you can assign any domain name you want to the device...
I guess that would work.
I guess that would work.
DaveOBrien 11/16/2022 01:38 PM
And provide a Lets Encrypt cert.
floitsch 11/16/2022 01:38 PM
That said: what do you want yourself to protect against?
There are multiple points of attack here.
There are multiple points of attack here.
floitsch 11/16/2022 01:39 PM
Actually.
floitsch 11/16/2022 01:39 PM
I think the biggest threat is that the certificate would be on the device.
floitsch 11/16/2022 01:40 PM
Currently the flash isn't encrypted, but that could be changed.
floitsch 11/16/2022 01:42 PM
The more I think about it the more I think this should work.
(that said: I'm no expert in TLS).
(that said: I'm no expert in TLS).
DaveOBrien 11/16/2022 01:42 PM
Yes, I expected the flash would need to be encrypted. I'd haven't come up with a solution that's clean. Even with secured certificate it would be painful to renew.
DaveOBrien 11/16/2022 01:43 PM
I am no expert in TLS either.
DaveOBrien 11/16/2022 01:44 PM
I wonder how secure http connection would be if the AP were limited to a single connection.
floitsch 11/16/2022 01:44 PM
There is a question of what you want to protect.
floitsch 11/16/2022 01:45 PM
Basically, the certificate ensures that the user can't be tricked into connecting to a different AP that claims to be your device.
floitsch 11/16/2022 01:45 PM
As such the user wouldn't reveal any important information to any other device.(edited)
floitsch 11/16/2022 01:45 PM
all of this, assuming that the user actually types in the
https://...floitsch 11/16/2022 01:46 PM
If the user just accepts any web-page, then man-in-the-middle of the AP is hard to prevent.
floitsch 11/16/2022 01:47 PM
You could, obviously, also use the WiFi encryption as safeguard.
floitsch 11/16/2022 01:47 PM
You can only connect to the device if you know the WiFi credentials.
floitsch 11/16/2022 01:48 PM
Nevermind. That password would, obviously, be known by some people, who could then create a man-in-the-middle AP.
DaveOBrien 11/16/2022 01:49 PM
I need to protect the machine/device from having unauthorised change to its settings and denial of service (ie device flooded with messages crashing main control application). If the ESP32 can't be adequately protected from DOS, it may be that the machine control microcontroller is a seperate device that communicates to the ESP32 say over UART
floitsch 11/16/2022 01:49 PM
In that case a simple login/password should be enough.
floitsch 11/16/2022 01:50 PM
The credentials for WiFi make sure that the communication is encrypted.
floitsch 11/16/2022 01:50 PM
You might not even need login/password, as the WiFi is already taking care of that.
floitsch 11/16/2022 01:50 PM
Only the people that have access to the WiFi password would be able to change anything on the device.
DaveOBrien 11/16/2022 01:53 PM
I think a risk is that someone impersonates the AP, then obtains credentials to change settings or disable the device.
floitsch 11/16/2022 01:53 PM
Without the password they can't impersonate the AP.
floitsch 11/16/2022 01:53 PM
This all relies on the fact that the ones that can change things don't leak the password.
DaveOBrien 11/16/2022 01:57 PM
I clearly have more thinking to do on options here. I haven't implemented bluetooth before, perhaps there may be a secure solution there that enables the operator to walk up and connect that way.
floitsch 11/16/2022 01:58 PM
Bluetooth would probably be nicer too, as the user doesn't need to connect to the AP.
floitsch 11/16/2022 01:58 PM
Also note: the certificate doesn't protect your device. It only protects your users so they know that they aren't talking to an impersonation.
floitsch 11/16/2022 01:59 PM
However, that's extremely easy to trick, if the user isn't really typing in the address.
DaveOBrien 11/16/2022 02:00 PM
Yes. for ease of use a captive portal would be nice but the user really wouldn't be paying attention then.
DaveOBrien 11/16/2022 02:01 PM
I will do some reading on bluetooth and secure approaches for pairing.
floitsch 11/16/2022 02:01 PM
sounds good.
floitsch 11/16/2022 02:01 PM
that said: if you need a TLS server on the esp32, it's feasible.
DaveOBrien 11/16/2022 02:02 PM
Thanks for looking at the issue and the chat.
floitsch 11/16/2022 02:02 PM
It would probably just require changing one flag in the sdkconfig.
floitsch 11/16/2022 02:02 PM
If you think it's something that would help, work under the assumption that you can have it.
floitsch 11/16/2022 02:03 PM
We would probably prefer not to include the TLS-server by default (as it takes space), but we could do that.
Alternatively, we are looking into making it easier to use custom ESP32 images, and this would be such a use case.
Alternatively, we are looking into making it easier to use custom ESP32 images, and this would be such a use case.
DaveOBrien 11/16/2022 02:03 PM
Great.
DaveOBrien 11/16/2022 02:04 PM
Also a side question - does Toit make use of PSRAM on the ESP32?
floitsch 11/16/2022 02:04 PM
not as much as it should.
floitsch 11/16/2022 02:05 PM
The ESP32 (earlier revisions at least) had a bug, and required a compiler flag to work around their hardware bug.
floitsch 11/16/2022 02:05 PM
When we tried to enable PSRAM we had difficulties with stability.
floitsch 11/16/2022 02:05 PM
We now think/hope that we weren't consistent in applying that compiler flag.
floitsch 11/16/2022 02:05 PM
We will eventually try to make it work again.
floitsch 11/16/2022 02:06 PM
Mikkeld (also here on discord) is using PSRAM successfully with Toit.
floitsch 11/16/2022 02:06 PM
I think he is using the esp32-s3, though.
DaveOBrien 11/16/2022 02:06 PM
No problem. I'll let you get back to your day - I'd better get to sleep here in Melbourne its 1AM
floitsch 11/16/2022 02:06 PM
good night then 
DaveOBrien 11/16/2022 02:06 PM
erikcorry 11/16/2022 04:13 PM
When you wake up:
For TLS the normal way around is that the device would verify it is talking to the correct server. This is what TLS is naturally suited for.
For example, there could be a physical button on the device. When the button is pressed, the device connects to a known wifi (could be provided by a phone with hotspot mode), then connects to a server over the net, which controls it. This could for example be a Supabase instance, hosted by yourself on Amazon, or hosted by Supabase.
The advantages:
* Device is a client - needs no TLS cert.
* Device verifies identity of the server
* The server can verify the device ID with a simple access key - each device has a different one, so there is not so much worry about it getting compromised. (optionally the device can provide a client cert so the server can verify the client - I think this requires patches to Supabase though).
* Since the device is a TLS client it doesn't need the TLS server code.
* Since the device is initiating the connection it doesn't need an open server port - less chance of DOS.
* If you later decide to add a cellular modem instead of the hotspot solution not much needs to change.
In order to control/monitor the device the tecnician's phone app could talk to the same Supabase server.
Disadvantage:
* The phone needs Internet access in order to provide a useful hotspot connection to the device.
For TLS the normal way around is that the device would verify it is talking to the correct server. This is what TLS is naturally suited for.
For example, there could be a physical button on the device. When the button is pressed, the device connects to a known wifi (could be provided by a phone with hotspot mode), then connects to a server over the net, which controls it. This could for example be a Supabase instance, hosted by yourself on Amazon, or hosted by Supabase.
The advantages:
* Device is a client - needs no TLS cert.
* Device verifies identity of the server
* The server can verify the device ID with a simple access key - each device has a different one, so there is not so much worry about it getting compromised. (optionally the device can provide a client cert so the server can verify the client - I think this requires patches to Supabase though).
* Since the device is a TLS client it doesn't need the TLS server code.
* Since the device is initiating the connection it doesn't need an open server port - less chance of DOS.
* If you later decide to add a cellular modem instead of the hotspot solution not much needs to change.
In order to control/monitor the device the tecnician's phone app could talk to the same Supabase server.
Disadvantage:
* The phone needs Internet access in order to provide a useful hotspot connection to the device.
erikcorry 11/16/2022 04:19 PM
Alternatively if there is no Internet access at all, the Supabase instance could be running on the technician's laptop, and the device connects to that.
93 messages in total