2

I read this before posting. I hope my question is on-topic here.

I'm working on an almost-IoT device that has a limited interaction with the Internet. Let's think about an "offline" product (say a lamp just as an example) with a module to expand some functions on the network.

Basically, it can exchange data on the LAN with other devices, it is connected to the Internet to retrieve the current datetime (NTP) and for firmware upgrade (not implemented yet).

But it also provides a webserver for user configuration and interaction. Although it is intended to be used inside a LAN, I cannot do anything if a user forward a port on its own router to access the web page from outside the LAN.

To avoid the more complexity about HTTPS, I was told to implement an HTTP server. But I wonder if this is acceptable for a commercial product, even within the specific context described above.

Eventually, my questions are:

  1. is it acceptable to use HTTP for a device potentially connected outside a LAN?
  2. if it's better/mandatory to go with HTTPS, is it acceptable to use self-signed certificates or we have to buy a "real" certificate?

I read this question, but the scenario is a bit different.

My concern is not limited about what a malicious user can do if he gain the access to the device only (he can turn on/off the lamp!) but if he can do anything bad on other devices too using ours as starting point.

Mark
  • 747
  • 1
  • 4
  • 13

3 Answers3

3

HTTPS won’t change a thing for your target scenario, it is designed to protect communication between the client and server, any intrusion in your system would be outside of its scope. The only thing it could change is protecting credentials transiting over the link, if those credentials are useful for the attack.

While you should use HTTPS, in this scenario it’s quite difficult to achieve something practical, as you need a certificate matching the name (or IP) of the device, while that name or IP is not available on the Internet, which makes certificate issuance more difficult. Self-signed certificates are not user-friendly and defeat the whole purpose of certificates.

Most common use cases nowadays are either that clients communicate with your device only using a dedicated app, which could have a better understanding of your own PKI (e.g. your own CA’s root certificate), or that both clients and devices communicate with a server on the Internet (your device would also be a client, probably using websockets), and communication between clients and devices go through that server.

An alternative if you use a dedicated app (especially on phones) is to use other protocols such as BLE.

Another possibility would be to use Let’s Encrypt’s other verification methods, such as DNS. You could then assign a name to each device pointing to its local IP address, and create a certificate for that. But be aware that I’ve seen cases of DNS-pointing-to-local being filtered out, so YMMV.

jcaron
  • 2,408
  • 5
  • 10
0

From personal experience, I hate all non HTTPS webpages inside my lan from the various IOT devices and routers etc. The browsers don't like and I have to press another button to get to them.

If it is going to be browser accessible then I would implement an HTTPS solution regardless of where it sits.

Rohit Gupta
  • 507
  • 2
  • 3
  • 18
0
1) Using HTTP for a device connected outside a LAN?

HTTP can be used, but be aware that HTTP traffic can be sniffed and read by potential intruders. HTTPS just provides you with the option to have end-to-end encryption between client and server.

Keep in mind that HTTPS does NOT protect you from intruders if your Apache(www server) is configured without proper care.

2) Self-signed certificates or "Real" certificates?

In terms of encryption level, they are the same. In terms of end-user conform, it is better to have "real" ones since you have them even for free of charge.

Amit Vujic
  • 750
  • 1
  • 8
  • 18