The local network is no longer a first class citizen of the web world. It’s easier to trust a faraway server than your NAS, TV or thermostat sitting right next to you. This is sad and could be different.
Before committing to writing a full spec I want to pitch the general idea. This due to the sheer amount of seemingly stalled efforts in this space (Network Service Discovery API, FlyWeb, raw-sockets, TCP and UDP sockets and numerous threads on this forum). My goal is to gather initial insight and discuss potential security implications before continuing towards a formal spec.
To ensure strict security, this effort aims to treat the LAN in the same way as the web at large. We don’t trust any devices by default and all security efforts, such as CORS and CSP, should apply.
The biggest missing piece for connecting to local devices is handling trust and doing it in a user friendly way. One can host a service on a LAN with self-signed certificates and add those to their certificate store. However, this is far outside the capabilities of a regular user. ChromeCast and similar technologies show that this can be done in both a user friendly and secure way. The proposed API would allow a browser to initiate a connection to a device on the LAN. The API can narrow down the devices it wants to talk to. The exact identification or filtering system can be decided later. This instructs the user agent to scan the local network and give the user an overview of compatible devices. The user makes his choice from the list. This prompts the user agent to start a handshake procedure. The first time this handshake takes place the user has to manually confirm the authentication using a ‘PIN verification’ step as used in ChromeCast or Bluetooth authentication. This is done to avoid MITM attacks. From that point forward, trust has been established between the user agent and said local network service. In practice this likely means that a self signed TLS certificate is now trusted for this device or service. I see this ‘trust’ or security context between the user agent and a device/service on the local network as orthogonal to the protocols that use it. Below I specify two potential uses: message passing and local HTTPS.
To be truly useful for IOT use-case the entire setup should work without internet access. This means, no cloud and no certificate authorities, only what is available on LAN. No-one likes it when their vacuum stops working because it can’t phone home to the cloud.
If I wanted to build a WPA that serves as a remote control for my TV it would be useless if I have to go through this consent flow every time. Therefore, the user agent can remember devices on two levels. First, when the user agent has a ‘trust relation’ with a service, it can re-establish the connection without the ‘PIN verification’ step. Secondly, the user agent can track access permissions per origin, just like is done for UserMedia. Finally, the user agent may choose to synchronize these settings across devices.
Giving access to low level protocols opens up a lot of security concerns. This proposal explicitly avoids that by letting the browser manage the trust relation with a local service or device. However, this means a new tailored protocol must be introduced. Just like ChromeCast it would use existing protocols under the hood, E.g.: SSDP/UPnP for service discovery and TLS for the handshake. Bridges can be built for backwards compatibility until devices adopt the new standard.
For use cases in IOT I suggest a simple message passing API that allows bidirectional message passing with the LAN device. As to not reinvent the wheel, this may be the WebTransport API that uses the security context provided by this proposal. Use-case include: Web based IOT hubs, remote controls, …
[Addendum] Local HTTPS
This approach would allow users to securely connect to services on their local network. Once trust is established with a local service, the resulting certificate can be used for a HTTPS connection. A variation of the above approach may open up an opportunity to combine HTTPS with mDNS. Potentially allowing you to directly navigate to an HTTPS mDNS URL, e.g.: https://device.local and letting the browser automatically trigger the verification and consent flow described above. Use-cases include: Finally being able to directly connect to a local NAS with a user friendly and secure context.