Initial release of Webinterface addon

[createcandle]

This addon offers an alternative way of controlling devices in your home while outside of your home. Even though this addon is nowhere near as powerful as the tunnel system, it could be useful in case the tunnel goes down.

Its main focus is privacy:

• Distributed. By default the addon uses the Candle webserver as the middleman. But users can run their own server, and it will work on cheap shared hosting.
• Anonimity. The server requires no identifiable information from the user (e.g. email address), and does not keep logs.
• Control. Outside access can be enabled and disabled at any time, and this can be automated with rules.
• Security. No ports need to be opened on the home system. Data is encrypted while in transit.

[createcandle]

Any update or feedback on this?

[tim-hellhake]

I'm not through it yet but I already have a couple of thoughts.

Why do we need a second tunnel system?
If you are concerned that your tunnel goes down you can already set up your own tunnel server right now.

You're pointing out that the focus is on security and privacy.
I would argue that the current solution is more secure and private than this approach.
Although the data is encrypted it doesn't mean that it's protected.
You can weaken encryption in countless ways by doing the smallest mistakes.
The current tunnel solution uses TLS which is a well-known standard.
AES is also a well-known standard but a good crypto concept is more than an asymmetric encryption algorithm.
TLS does not only protect the data but also verifies that you talking to the server you are expecting to.
Additionally, you are storing data that is a high-value target.
The current tunnel does no such things.
There is neither data nor a password that can be stolen.

There are already instructions in the readme on how to sideload the addon.
Given the fact the this seems to be a corner case and can potentially weaken your security, I would say this a good candidate for the side-load installation process.

[createcandle]

Thanks for taking the time to look into it! I'll try and address your points one by one, and try to explain in more depth how the addon works.

If you are concerned that your tunnel goes down you can already set up your own tunnel server right now.

Not really? That requires a serious webserver and serious skills. This can run on shared hosting, and is a drop-in solution.

You can weaken encryption in countless ways by doing the smallest mistakes.

That's absolutely true, but in this case I don't think it applies. This uses a bog-standard AES solution, nothing custom.

There is neither data nor a password that can be stolen.

• The password is never transmitted over the internet. Not even encrypted. This means it's also never stored on the webserver. The user chooses a password on the gateway, and data remains encrypted during transit until it's decrypted in javascript in the browser, where the user would also enter the password. All that is used to match the server and browser is a hash. So this is not a a-symmetric encryption implementation, but a symmetrical one. No complex key exchange is required.

This solution does store data on the webserver, but only sometimes.

• Firstly, this addon allows the user to disable the outside access at any time, by creating a thing with a toggle. So 99% of the time the addon would not even be uploading data. This is importantly to me: I cannot currently disable the tunnel whenever I like. It's "always on". That's uncomfortable to me.
• On top of that: even if outside access is enabled, still no data is sent to the intermediary server. The addon will poll with the webserver to ask if someone is actually logged in. Only when the user is actually logged in to the intermediary server, then the correct hash will temporarily be stored there (generated in the browser client), and only then will the server start uploading encrypted data.

So there is almost never data on the server.

Further, any data is also deleted as soon as possible. Both the server and client will try to delete any data if it notices the other party it no longer there.

• If the gateway has uploaded data, then this data may be downloaded by the client for a few seconds, and the server deletes it. For example, if the user closes the browser window, the gateway will no longer see a recently timestamped hash on the webserver, and then the uploaded data will be deleted.
• Going in the other direction, the client may generate a list of encrypted "action" commands. For example, to turn on a light. The client uploads this list to the intermediary server. The gateway keeps polling for commands, and if there are any, they are downloaded and then deleted from the server.

Put simply: if the user is not actually logged in from the outside, then there is no data stored on the server.

TLS does not only protect the data but also verifies that you talking to the server you are expecting to.

This addon has a similar protection, in that the gateway will attempt to decrypt the commands it periodically downloads from the intermediary webserver. Even if the assailant could redirect or has control over the server, that won't help them. If the assailant doesn't have the password, they cannot create valid commands. This is one of those cases where Alice and Bob are the same person, so all the issues with asymetrical key exchange are not a factor here.

Replay attacks are also not possible, since the addon checks the timestamp that comes with each downloaded command. This stamp may not be older than 15 seconds. This timestamp is inside the ecrypted payload, so it cannot be changed on the webserver.

I would argue that in some ways this addon is more secure than the tunnel system.

• While the tunnel gives full access to the gateway, this addon only allows an outside user to read and change thing data. Outside users cannot create rules, change settings (or passwords), install addons or other software, check logs, and so forth. This limited scope makes it harder to do damage if the password got in the hands of a malicous actor.

Privacy is also stronger, since this solution can be used much more anonymously than the tunnel system. To use the tunnel users must create an account, which involves sharing their email address. They have to agree to a privacy policy. I'm not sure how the tunnel tech works, but I suspect the cloud server needs to be kept informed what the IP address of the gateway is. In contrast, the WebInterface addon collects no personal or even aggregated data, so a privacy policy is not even required.

This design also makes it more secure: if someone hacked the intermediary server, there would be no meta-data there that could lead an attacker to figure out who the encrypted data even belongs to. There is no email address sent to / on the webserver, since it's never collected in the first place. All they would have, if they hacked it at the right moment that a user is actually logging in from outside, is an anonymous ID, a hash, and an encrypted string. And perhaps IP address if they want looking in server logs. I would hope that's about the same they would find on the tunnel server (and it may be less).

Some smaller arguments that rely on a broader definition of security:

• The tunnel, while secure, is complex. This gives it a pretty big attack surface.
• The tunnel server is a juicy centalised target. This addon allows for a federated multi-server solution, where users are spread over multiple servers. This potentially makes each server less of a valueable target.
• User's own webservers might be more secure than the tunnel server implementation.
• I believe the tunnel relies on Amazon servers? With my own server I know it's running inside the EU, which offers better legal protections.
• This addon can be used through TOR. Someone living in a country with a repressive goverment could still gain access to their gateway without fear of blocking or worse.

Given the fact the this seems to be a corner case and can potentially weaken your security, I would say this a good candidate for the side-load installation process.

I hope I've been able to explain why this solution is not insecure, and it could be argued that it is more secure.

I didn't build this just to handle the corner case that the tunnel was down. I built it because I wanted a solution for outside access that..

• is more limited in scope (only control devices, nothing more).
• is under my own control, running on servers I trust.
• potentially federated (not one big juicy central American server).
• can be used anonymously.
• could be installed even after a user initially declined to create a tunnel account.
• could be turned off.

Finally, I don't build addons for them to then require side-loading. Information on how to do so in only on Github for beta-testers, and is not intented as a permanent solution. I build addons to give people options. If people don't want to use this addon, then they should not install it.

Anyway, I hope this information was useful in explaining how the addon functions, and why I believe it's a valueable option to have.

[createcandle]

It would be nice to have this accepted. We had the whole debate around the idea that the 'community version' of the Gateway should be very accepting to new addons. In this case to support research into new privacy protections for smart homes.

[kgiori]

@createcandle -- I think that if you put that full, long, complete description of how this works in the readme of your add-on, which is linked directly from author name in the gateway add-on list, then it should be acceptable as a general add-on. it's basically this message to the user: "Use this as a choice if you want more privacy and trust the intermediary server". I also like having an alternative approach available since at some point centralized tunneling doesn't scale, it's costing someone we know money to host, and I wonder if it even works at all in China.