benfrancis
commented
7 years ago CC @pauljt
I'd like to try and clarify the problem we are trying to solve...
Background
We have created a "web of things" gateway people can build themselves using a Raspberry Pi which enables you to monitor and control connected devices in your home over the web via a web application hosted on the gateway itself.
Secure remote access is achieved using HTTPS and a username and password configured on the gateway during first time setup. We provide a TLS tunnelling service which for convenience during first time setup allows users to easily set up a secure subdomain to access their gateway over the web. The Getting Started Guide shows how this works from the end user's point of view.
The service works by issuing a free subdomain, generating an SSL certificate via LetsEncrypt and setting up a secure tunnel from a Mozilla cloud server to the gateway using PageKite so that users don't have to manually open and forward a port on their router to the gateway. The initial setup of the tunnel happens over plain HTTP (via gateway.local over mDNS or a local IP), but after that point everything (including configuring the username and password) happens over HTTPS (e.g. https://foo.mozilla-iot.org). The user is free to configure DNS, TLS and NAT manually themselves if they want to use their own domain name or don't want to tunnel their traffic through a Mozilla server.
Problem
The problem with this is that when the user's Internet connection goes down, they can no longer access their secure subdomain even from within their local network, because HTTPS relies on DNS which relies on having an active Internet connection. We would like users to be able to continue to turn lights on and off from within their home when their Internet connection goes down!
Potential Solutions
Plain HTTP
Users could potentially still access their gateway using its local IP address (or gateway.local mDNS broadcast), but this would only be available using plain HTTP.
Some people would argue that plain HTTP inside the local network is actually fine and is how the vast majority of home routers work today, but many people think that with all the connected devices we're adding to our networks, we can no longer trust the devices on our own local network. An untrusted device on the local network could use a MITM attack to steal the password or JSON Web Token as it is exchanged over HTTP.
Manually switching between different web addresses depending on whether your Internet connection up is not very user friendly! Also, the web app hosted on the gateway is designed to be used in a standalone display mode without a URL bar. It's possible we could use Service Workers to automatically fail over to API calls in plain HTTP if the HTTPS connection is unavailable and client is connected to the same local network as the gateway, but that could be tricky to detect.
DNS Caching
We experimented with DNS caching to allow continued access to the gateway over HTTPS during a temporary Internet outage, but we concluded that DNS caches in operating systems, browsers and routers are just too inconsistent and unpredictable to make this a reliable solution.
WebRTC
One proposed solution involves using WebRTC to create a secure peer to peer connection between the browser and the gateway which doesn't require HTTPS in order to continue working.
The purpose of our project is to "give things URLs on the web" and using a P2P WebRTC connection wouldn't really be achieving this as such, it works around it. Also WebRTC can be a very complex technology to set up and get working and in some cases requires a centralised server to initiate the connection.
Plain HTTP with custom encryption
Another proposed solution is for the client and the gateway to exchange keys of some kind while the HTTPS connection is available, so that they can continue to communicate securely over plain HTTP and be confident of each others identity when the HTTPS connection is unavailable. I suspect this is similar to what HomeKit does (Apple Developer registration required to view), by layering a custom security mechanism on top of plain HTTP.
The downside of this is that it requires custom encryption of the JSON payloads of REST/WebSocket API calls which may harm interoperability if everyone on the Web of Things used their own encryption scheme.
I think that's most of the solutions we have explored so far.
Requirements Recap
To recap, the requirements are:
- Provide secure access to the gateway over the web
- Continue to provide reasonably secure access to the gateway from within the local network when the outside Internet connection goes down (it can be assumed that an Internet connection was available during first time setup and most of time after that point)
- Ideally accessible from a web browser from within the local network, but requiring a native app for special features could be OK (e.g. "the web app only works with an Internet connection but a native app can also provide local access while offline" could be an acceptable compromise if no other solution is available)
- Not rely on a centralised Mozilla-hosted cloud service so that users can choose to use the gateway independently of Mozilla if they want to or if Mozilla shuts down the service (e.g. by configuring their own DNS, SSL and NAT).
Note: This last point means that the "explicit trust" approach described above where authentication happens using a Mozilla cloud service is far from ideal. The core principle of Project Things is to create a decentralised IoT using lessons learned from the web, which doesn't rely on a central point of control.
It may be that we come up with two solutions:
- A short term hacky solution which is "good enough" but keeps us webby and fairly decentralised
- A long term solution baked into the protocols of the web itself, like an enhancement to HTTP, HTTP/2 or SSL designed to solve this kind of problem more generally
Some other solutions may become possible if the gateway is also the home router and provides the DNS configuration for the home network. It would be useful to discuss these solutions because it may be that at some point this becomes true, although for now the gateway is a Raspberry Pi separate to the home router.
hobinjk
martinthomson
daniel-kun
X-Ryl669
When the internet is down we want to have a mechanism where we can still communicate with our devices (provided we are on the same network as those devices). To facilitate this we need some sort of "trust" mechanism where we use a trusted third party to exchange public keys.
We need to initially support two modes initially for this:
Implicit trust between gateway and client (they exchange public keys directly, potentially without protocol level security).
Explicit trust of a third party (i.e. cloud.mozilla-iot.org).
Requirements for implicit trust (required for this release):
[ ] Client is directly "logins in" with the gateway and will be given (in addition to their own public key) a public key for the gateway (which is used to verify messages from the gateway).
[ ] Client is given some mechanism (probably an ip to start) to discover gateway offline.
Requirements for explicit trust (may be moved into future release):
[ ] Restructure gateway so we can reuse (or perhaps just extract) login logic to a centralized cloud component (logins by the nature of this system must happen through this system in this configuration).
[ ] Gateways in "explicit" trust mode must register themselves with the third party entity (on first time setup). Gateways do not store the hashed password in this trust mode.
[ ] Logins in "explicit" trust mode must happen (i.e. password hashes are sent to) the trusted third party (mozilla-iot cloud or similar) and public keys are registered with this entity.
[ ] Client is given some mechanism (probably an ip to start) to discover gateway offline.