-
-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remote WebSocket Connection #4118
Comments
@phillclark I don't think that adding a backdoor for remote command & control is a good idea, considering that IOT devices are always a good target for remote exploitation. We would first need some kind of public key encryption support for JSON commands in WLED, to ensure that the "JSON control" data comes from a trusted source. Otherwise the server (name or ip) could be spoofed easily, and a malicious attacker might be able to send some JSON commands that overload your wiring, by simply forcing all your LEDs to bright white. |
Additional note: As WLED already supports websockets (as a host) you can update a client to reconnect to WLED when it becomes available and control it. |
@softhack007 I think this is a real edge case scenario - there would be protections, as you state that could be added. It might not even need that level of security; you could set a salt on the device and then as part of the payload sent include a hashed value combining the JSON and the salt for a checksum comparison when received on the device. Ultimately, the implementation of this would be down to the user to ensure they have secured the process between the device and the remote WS server in a suitable way. It would be a lot of effort for an attacker to find, spoof and then send commands to realistically change the colour of some LEDs! In terms of overloading wiring, well anyone installing should be factoring maximum power potential and installing it with suitable wiring, power supplies and protections anyway! ;-) @blazoncek this is fine if you have access to the local network where the devices operate; I have scenarios where I cannot get remotely into the network due to firewall rules so then have to run additional kit to act as the go between making the remote connection outbound and then relaying commands to the devices locally. My suggestion was to remove all the additional complexity on this front to then allow the device itself to make the connection direct outbound. |
You have a usermod for that. Called something like "Http pull request". |
@blazoncek I couldn't see anything obvious in the usermods along this line - if you can point me at it that would be great! |
Look at 0_15 branch. |
@phillclark look here https://github.com/Aircoookie/WLED/tree/0_15/usermods/usermod_v2_HttpPullLightControl |
Add the ability for WLED to make a connection to a remote WebSocket so on boot it will attempt to connect to a designated location and then recieve commands from that source. JSON structure would remain the same for the actual controls.
The text was updated successfully, but these errors were encountered: