https://toitlang.org/ logo
Join Discord
Powered by
server_tls.toit examples throws exception when cli...
# help
d
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: 
jag pkg install http
and install the container: 
jag container install https-server server_tls
then: 
jag monitor
I browse to 192.168.23.115:8080 and get the following output / error:
Copy code
...
[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 available
Any guidance appreciated. For refererence SDK is v2.0.0-alpha.37 and hardware is ESP32-DevKit4-VE
f
@erikcorry . Any idea?
e
Are you running the server on the device and connecting from your host workstation, or are both running on the device?
d
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.
e
Are you using Jaguar? If so, so you see the little web page Jaguar serves up on http://192.168.23.115/ ?
Ah, I think that perhaps you are connecting with HTTP from Chrome, but the server is set up to use TLS (HTTPS).
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.
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.
To get this to work you would need a real certificate from eg LetsEncrypt.
d
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 
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
f
Could you maybe try to run the same program locally? Just to see if it works there?
(while we wait for Erik)
d
Sorry, what do you mean by locally?
f
jag run -d host $path_to_entry_point
This will start the program on your desktop machine
Obviously, this won't work if you try to access gpio pins or so.
d
I haven't run on the host before, is there any setup to run.
f
As long as you have 
jag
you shouldn't need any setup.
You can try with a simple hello_world.toit example first if you want to.
It's just an easy way to use Toit on the desktop.
e
I tried running on the host and it works as expected.
I'm running origin/main of the pkg-http from github.
f
Edit: oops. got messages mixed up. So when that runs you can access https://localhost:8080 ?
d
So hello world runs on host.
the https-server doesn't but I haven't installed the pkg-http yet
f
How did you build the https server in the program that is running on your ESP32?
nevermind. Just reread the first message.
e
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.
f
Can you show us the command line you used to run locally (where it has the bad certificate error).
And then the command line you used to install on the ESP32.
(In the meantime I'm trying to reproduce on my own ESP32)
d
How do I install the pkg-http on the host?
f
no need.
I can reproduce.
d
okay
f
I think this is the reason:
Copy code
# CONFIG_ESP_TLS_SERVER is not set
We recently modified our build-process and seem to have inadvertently changed this configuration option in the sdkconfig.
that said. This is the ESP server. We might actually not need that. Let me investigate.
This looks more relevant:
Copy code
# CONFIG_MBEDTLS_TLS_SERVER_AND_CLIENT is not set
# CONFIG_MBEDTLS_TLS_SERVER_ONLY is not set
CONFIG_MBEDTLS_TLS_CLIENT_ONLY=y
e
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.
d
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.
f
And since you are in AP mode you can assign any domain name you want to the device... I guess that would work.
d
And provide a Lets Encrypt cert.
f
That said: what do you want yourself to protect against? There are multiple points of attack here.
Actually.
I think the biggest threat is that the certificate would be on the device.
Currently the flash isn't encrypted, but that could be changed.
The more I think about it the more I think this should work. (that said: I'm no expert in TLS).
d
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.
I am no expert in TLS either.
I wonder how secure http connection would be if the AP were limited to a single connection.
f
There is a question of what you want to protect.
Basically, the certificate ensures that the user can't be tricked into connecting to a different AP that claims to be your device.
As such the user wouldn't reveal any important information to any other device.
all of this, assuming that the user actually types in the 
https://...
address
If the user just accepts any web-page, then man-in-the-middle of the AP is hard to prevent.
You could, obviously, also use the WiFi encryption as safeguard.
You can only connect to the device if you know the WiFi credentials.
Nevermind. That password would, obviously, be known by some people, who could then create a man-in-the-middle AP.
d
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
f
In that case a simple login/password should be enough.
The credentials for WiFi make sure that the communication is encrypted.
You might not even need login/password, as the WiFi is already taking care of that.
Only the people that have access to the WiFi password would be able to change anything on the device.
d
I think a risk is that someone impersonates the AP, then obtains credentials to change settings or disable the device.
f
Without the password they can't impersonate the AP.
This all relies on the fact that the ones that can change things don't leak the password.
d
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.
f
Bluetooth would probably be nicer too, as the user doesn't need to connect to the AP.
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.
However, that's extremely easy to trick, if the user isn't really typing in the address.
d
Yes. for ease of use a captive portal would be nice but the user really wouldn't be paying attention then.
I will do some reading on bluetooth and secure approaches for pairing.
f
sounds good.
that said: if you need a TLS server on the esp32, it's feasible.
d
Thanks for looking at the issue and the chat.
f
It would probably just require changing one flag in the sdkconfig.
If you think it's something that would help, work under the assumption that you can have it.
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.
d
Great.
Also a side question - does Toit make use of PSRAM on the ESP32?
f
not as much as it should.
The ESP32 (earlier revisions at least) had a bug, and required a compiler flag to work around their hardware bug.
When we tried to enable PSRAM we had difficulties with stability.
We now think/hope that we weren't consistent in applying that compiler flag.
We will eventually try to make it work again.
Mikkeld (also here on discord) is using PSRAM successfully with Toit.
I think he is using the esp32-s3, though.
d
No problem. I'll let you get back to your day - I'd better get to sleep here in Melbourne its 1AM
f
good night then 🙂
d
😴
e
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.
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.
PreviousNext
Powered by