Actually secure HTTPS connection / stable node-id

Currently you can configure in the node that it should use a secure (HTTPS) connection. I think we’re applying the wrong kind of security there, without really understanding what is actually secured this way. I would like to propose a better/improved way.

Have a look at the key concepts of computer security:

What the current mechanism using HTTPS does, is making sure that the node checks that the server is the authentic sensor.community server (not to some faked sensor.community server). Then communication with that server is made confidential. Spoofing the sensor.community server would make little sense, so protecting against it with https also makes little sense. The data sent over the connection is essentially open data, so you could argue that using the confidentiality feature also makes little sense.

What the current scheme does not protect against, is spoofing node ids or even node data. Nodes are simply identified by their “unique” ESP-id, but people can make up their own ids, possibly ids can be duplicate (because you have no control over whether ESPs have duplicate ESP-ids) and people can make typing errors. Even though a node verifies that the server is authentic, there is no check the other way around, that node data is authentic. Data can even be spoofed if you know the hardware id of a node.

What would make sense to me, is that the server creates a node id plus some secret code. The user then puts those two credentials in their node. This way the server can verify that the node is authentic. If a node gets lost or stolen, the credentials can be retracted so the node can no longer send unauthorised data.

This could also solve the problem where the nodemcu dies and you get a discontinuity in your data (because the esp8266/nodemcu id changes when replacing it). In the proposed new way, you no longer use a hardware-id, but a server-side generated id. You simple throw the old nodemcu away and put the credentials in the new nodemcu.

Using this new method would require you always use HTTPS, to keep the id + secret code confidential.

As a way of transitioning, you could do something like this:

  • For current nodes without a secret, the server does not have a record of a secret key, so for those nodes it does not check any secrets, things keep working as they do know
  • For new nodes, let the server create a node id (server can guarantee uniqueness) plus a secret code. Allow the user to copy the unique id + this code from devices.sensor.community | lietotāja konfigurācija into their node during wifi setup.
  • When the node connect, the server notices that this node has a secret code, and verifies it. Data can not be spoofed, because that would require knowledge of both the id and the secret code.

What do you think?

3 Likes

Now that I’m thinking more about this, I realise that there is basically already a server-side id, either:

  • the location id, or
  • the database-id/sensor-id as displayed on the map

I still think this would be a good idea because it addresses two problems at once: make the connection actually secure and provide a way for people to continue their measurement series if the nodemcu breaks down.

Any other thoughts?