Secure local and remote access to self hosted devices without manual setup

[EternityForest]

Introduction

In the IoT era, it is more and more common to have a need to remotely access a device located in a user's home or business. The current method for achieving this is almost entirely cloud-centric, which has notable disadvantages, especially in underprivileged areas or for critical equipment.

I propose a new protocol, which would allow for greater security and convenience in both remote and local access.

I have prototyped and refined this protocol in limited form as a standalone app, and believe it to have good usability and security.

As I've never written a proposal here before and this spec is rather complicated, I had trouble balancing generality and detail, but I believe this to be sufficient information to evaluate it.

Use Cases (Recommended)

• Remotely accessing a consumer grade home automation system or smart camera, without any middleman

• Setting up devices such as routers without relying on unencrypted HTTP or the cloud

• Serving local content on a private network at an event, accessible via QR code.

• Self-hosting more traditional applications such as chat servers or personal file storage.

• Allowing a traditionally-hosted web app to communicate with a locally-hosted service, such as a management site for a smart TV.

Goals

• Allow a user to discover applications, and connect to them.

• Provide similar security as other trusted modern protocols without requiring a certificate authority or extensive manual setup.

• Allow local connection to open source devices without trusting, or even needing to access, any device outside LAN.

Non-goals (Optional)

This protocol is not intended to specify any particular
"Web 3.0" features, and is only meant to be an extension of the use cases generally covered by a dynamic DNS service and a free SSL certificate.

It is also not in any way intended to replace a VPN, it just makes individual services remotely accessible.

Proposed Solution

A new protocol scheme, would be created to handle URLs that embed the server's public SSL key used for transport, along with a discovery scheme to resolve such URLs.

This would allow one to use a self-signed certificate(which may by generated onboard a device, for total E2E security), as the URL itself specifies the trust.

This kind of approach is already widely used in rather critical applications, in the form of "Anyone with this link" sharing.

Discovery

Discovery would have several modes, both built-in and pluggable.

The primary discovery mode would be a privacy-enhanced MDNS service type that would hash the special URL with the current time, rounded to the hour, to produce a discovery string, which would become part of an MDNS name.

This would ensure that users could not be tracked on public WiFi by observing their device's attempt to contact their home hub.

Implementing this alone would already cover a large number of use cases, meaning features could be added in an incremental way.

Upon connecting in this way, an additional in band step would allow the device to supply a set of public IP addresses.

These public IP addresses would be cached long term(weeks to months) for later use in connecting when outside the network. The host or user would be responsible for opening ports or whatever else was needed to make these URLs work.

As even dynamic IPs rarely change, this would enable remote access most of the time after connecting once locally, even if other discovery methods failed.

In the case of some mesh networks, this would be enough to be reliable indefinitely as IPs are based on cryptographic identifiers.

However, since IPs do change, and it is the intent of this proposal to enable sharing to anyone the user wishes, a secondary discovery method would be used, wherein the URL of a discovery server could be embedded directly in the main URL.

This discovery server URL would be passed the same rolling-hash string discussed in local discovery, and would be expected to return a list of IP addresses or traditional DNS domain names at which the device could be accessed.

As P2P technologies such as distributed hash tables are still extremely unstandardized, it does not make sense to attempt to add anything of the sort to this specification.

Instead, software and hardware vendors would create their own remote discovery servers, use public DHT key-value gateways, or perhaps implement some future true P2P method using service workers.

One important note is that the discovery server can be another self-hosted P2P URL. This is important as the system should be fully usable in an offline mesh scenario.

Traditional DNS is undesirable here due to the very high rate of change in lookup key, caused by use of rolling code.

URL Portability

It is important to note that this additional information contained in the URL bar should not change the unique origin associated with the URL.

This means that a device owner could easily take a device URI for a no-longer-supported hardware devices, open a port manually, and create a new URL to access it via some other means, without compromising the security provided by the embedded key itself.

As a convenience, a URL could even directly include an IP address for the host, providing a quick way to manually make a connection in case the discovery server fails.

UI Considerations

As with Bluetooth, the concept of "Pairing" could be used to enhance security. Pairing would be done via a new UI menu that could scan for devices.

Access to unpaired devices via this method could be treated as an insecure context.

Services could be associated with a title, which would be shown in the URL bar for that service once paired.

For enhanced security, users could be prompted to enter their own title, preventing bad services from showing trustworthy-looking things in the URL bar to people who just click through.

Security Enhancements

In addition, as an extra layer of security, not intended to replace logins, URLs would embed a strong random password which the server would require for connection, sent in a small JSON negotiation step after SSL setup before HTTP traffic begins.

While this password could be visible during discovery, it could not be found by an attacker with M2M or sniffing capabilities on networks other than the one containing the server, making attacks much harder.

For enhanced security, discovery could be entirely disabled by the host, making this password, providing full protection.

This password would not affect unique origin and could be freely changed.

Even in cases where the device itself had poor security, the pool of possible attackers would be mostly limited to those who already had access to the user's network, providing at least as good of security as a traditional unencrypted device admin page, protecting users from poor quality firmware.

Beyond this, as the URI scheme does not currently exist, it can be treated differently with respect to CORS, disallowing any POSTs from any other server without a preflight, and any other strengthened restrictions that may be desired in a "fresh start".

As CORS may be a highly uncommon use case, even GET could require a preflight, to further guard against the dime-a-dozen low quality devices on the market.

Similarly, non-preflighted requests FROM pages using the new scheme could be forbidden, to protect in cases of unrelated vulnerable services on the public internet.

Corporate Environments

Many situations call for a secure intranet, and this proposal could not be used unmodified by any company that did not trust employees not to discover and pair with random things that a threat actor could sneak onto the network.

This issue is mitigated by browser management rules, which could disable the feature entirely, restrict it to a certain set of URLs, or mark certain URLs as approved, or simply disabling discovery, and using out of band means to distribute URLs.

Examples

Theme Park

A park would like to make information such as maps available to all guests. Some of this information may be highly dynamic such as current ride closure conditions.

Router setup

A router has advanced features such as NAS functionality. A user plugs in the router and opens an instruction manual, where he is guided to connect to the router's hotspot, and visit the "Nearby Hosts" page of his or her browser.

He opens the browser page and sees that there is a service labeling itself as a router.

Clicking it, he is asked to confirm the pairing. The prompt informs the user that you should only pair a device if you are on a network you trust.

Once paired, he is taken to the router admin page, and enters the password from the bottom of his router as normal.

For remote access, the router manufacturers would of course need to run a discovery server, and embed code into the router to discover via this server.

As the connection is now a secure context, this router may provide advanced personal cloud features like offline-first service workers and WebRTC chat.

With enhanced security

In an enhanced security scenario, using a router with more advanced capability, the router could disable discovery and provide an NFC or QR code via LCD containing the secure URL.

In this scenario the user is partially protected even if they reuse a password, or have attackers that can intercept traffic right on their network.

Privacy & Security Considerations

The primary consideration I see is that someone may make a malicious server with whatever title they want.

However, this same attack vector exists in Bluetooth, using the same pairing-based trust model, and it seems to be within generally accepted industry practice.

In addition, it is mitigated by the URL-based nature, which allows for secure out of band transfer that does not rely on discovery.

The use cases covered by this proposal are currently covered by things like plain HTTP or Bluetooth itself, so there should not be a decrease in security.

As I see it, issues like tracking via the lookup resolvers are similar to the issues presented by any other current web tech.

There may be concerns with harmful or spam-filled sites on public networks, which may be harder for law enforcement to trace as there is no domain owner.

However it is a fairly poor vector, that does little one could not already do with a local IP and a QR code, and if it were considered an issue could be solved simply by removing the discovery feature.

One possible scenario where it could be an issue is a user creating a fake service having the same title as one ran by a business, and advertising it via local discovery from a hidden device.

Again, considering typically poor physical security in the world, this doesn't do much that could not be done by putting up a QR code or any other malicious signage.

A compromise mitigation might be to exclude general discovery from the browser, allowing technical users to download general scanner apps, and others to use NFC setup or manufacturer-specific apps that will only respond to signed devices.

Another potential issue is confusion caused by sending people links to sites with malicious titles, and getting them to trust them via social engineering.

This threat should be the same as any other malicious link. To reduce it further, URL titles could carry restrictions, such as not being able to end with a standard TLD.

One thing that would seem to largely mitigate the risk, is that discovery is entirely driven by the user. No notifications would be shown, preventing use in spam.

As mentioned above, allowing only user-selected titles prevents one clicking through a pairing process without thinking, and then seeing what appears to be a bank URL or such in the URL bar.

Furthermore, as the intention is to support locally hosted services that do not depend on the internet, payment-related APIs could be disabled on these devices.

Another notable consideration is that someone with physical access to a machine could set a malicious title for a paired device, tricking the user when they return.

This could already be done rather easily through a normal phishing URL, but in this case could be harder to prosecute. This scenario is partiality mitigated by restricting titles.

[LJWatson]

@ashimura, is this something the WoT WG might be interested in?

[backkem]

This sounds like a use-case that we could support as part of the Local Peer-to-Peer API. The Local Peer-to-Peer API currently describes discovery & peer authentication for local peers (or devices) for the use of bi-directional communication. We also want to leverage the resulting trust (mutual TLS certificate pair) to discover and secure local web services as briefly described under Local HTTPS. There is also intent to explore alignment with Matter for IoT use-cases (w3c/openscreenprotocol#308).

Remote (WAN) use-cases are currently out of scope of the effort but it can be explored in future work.