Disable discovery and server?
hspaay opened this issue · 7 comments
Hi, just getting started and please forgive my ignorance if the question doesn't make sense.
webthing-node starts a server that can be discovered and connected to. However there are a few reasons why this is not always desirable:
- No centralized permission management. Permissions need to be set per instance.
- A network with VLANs doesn't allow for discovery
- The current approach only works on fully trusted networks. In case of remote IoT devices such a network might not be available.
- Security concerns. Minimizing attack footprint by only allowing access to a gateway.
In theory, is it possible to turn off the server completely and configure it to push the discovery and status updates to a gateway?
(even if it requires an update to the gateway). This allows a single point for contact and authentication for all instances by the end user.
Thanks
Just to clarify, do you want to disable both the web server and the mDNS server?
Yes, for these use cases receiving anything from the local network is undesirable. That makes publishing mDNS discovery unnecessary.
As a side note, webthing-node will need a plugin to publish the discovery info to a web service or to the gateway for this to be useful. Not sure if the current gateway supports this already but that is a different topic (and a chicken-egg problem)
If there’s no web server, then there is no web thing API, and thus no way to “push” anything to the gateway. It sounds like what you want is just an adapter add-on for the gateway.
@mrstegeman Ah interesting, what I had in mind (possibly incorrect) is to use the webthing-node library to push data into the gateway, without running as a server. For this the gateway would be a server and expose a standards based API that webthing-node implements. This model is similar to that of the FiWare context broker. It is also how I interpreted "4.1.13.1 Connected Car Example" in the WoT architecture document and 4.2.6.2 Legacy Devices
If I understand you correctly, this is not the purpose or design of webthing-node and out of scope.
So if I implement an add-on for the gateway, would this be re-usable by other gateway implementations? Is the internal gateway API standardized as part of WoT? The concern I have is that the addon is implementation specific to the gateway implementation and not reusable.
There are a couple additional concerns,
- The gateway does two things, the data aggregation and the presentation. (maybe the presentation is a plugin too, in that case this is incorrect).
- When using webthing-node, every appliance exposes its own API. If I've learned anything from IoT devices is that this is the last thing you want. It is easier to protect one gateway than hundreds or thousands of IoT devices. Point in case CoAP reflection DDOS attacks.
Thank you kindly for explanation.
I'll close the issue since you answered the question.
Many thanks @mrstegeman
Hi @hspaay, as @mrstegeman explained, having devices acting as web servers (or being proxied to a web server using a gateway) is fundamentally how WebThings (and by my understanding the Web of Things in general) works. If a thing doesn't have a web URL then it isn't a web thing.
However, requiring that all Web of Things devices expose a web server to the Internet does have its downsides, as you have identified.
A couple of people have suggested the idea that the webthing WebSocket sub-protocol could also work the other way around, i.e. the device acts as a client which opens up a WebSocket to a web service hosted elsewhere. The same messages would be sent back and forth, but the WebSocket would be opened up in the other direction. This would have benefits for a lot of use cases where traversing a firewall is not desirable or convenient and would make it much easier to deploy those devices. The downside of this is that those devices are no longer discoverable or linkable, which although perhaps desirable in some use cases, are two of the fundamental properties of the Web of Things as I understand it.
Although not the original intended purpose, you might want to suggest this as a use case of the Web Thing Protocol, in response to the current call for use cases and requirements.
@benfrancis @mrstegeman looks like we are getting to the crux of the matter. I realize this is out of scope for webthing-node, so I posted a separate issue for this at w3c/wot-security#197.
That said, probably good to clarify something. I realize in order to communicate with an appliance there has to be a server and client role. The architecture document has plenty of examples. This applies to the data flow however and does not require that the appliance listens for commands on an open port.
As Ben pointed out, the WebSocket sub-protocol lets the data flow go either way, independent of the connection control. FiWare has support for MQTT as a notification channel. Either way there is no need to run a web server on each appliance. If the discovery process is reversed, the appliance discovers the gateway and connects to it and the gateway sends commands over WebSocket we can disable the server on the appliance. What is most unfortunate is that currently there is no spec or API (that I'm aware of) that supports this approach. As a security conscientious developer I am forced to create an insecure solution to remain compatible.
Also please note that you cannot assume the LAN is safe. For example, your web browser runs code (javascript, wasm) that is downloaded from the internet and you have no control over it. There are plenty examples how to probe devices on the LAN from JavaScript so sooner or later someone will figure out how to connect to WoT appliances and take over control.
Ben, I'm sure we can come up with a solution to the discoverability or link-ability that is more secure. For example, an unlinked device can still run a web server that is disabled when linking is established. A reset can unlink it again. My main issue is that if I want to improve security by disabling listening ports, currently there is now way to do so. I think WoT has a responsibility to establish and push for best practices that are secure.
Ben thanks for the link, this is great.