1

The company X is selling its home made IoT device.

Each IoT device is only communicating over Internet with a web server of the X company, using HTTPS (with state-of-the art configuration : latest TLS protocol, higher cipher suite, etc).

Is there any good security reasons for the X company to encapsulate the HTTPS traffic in a VPN (initiated by the device) which would connect only the device to the web server ?

Please note we are here in the M2M world, there's not any browser involved at all in this chain, and not any user or GUI on the Iot device. Thanks for your answer !

4 Answers 4

3

No.

Let's have a look at what you generally want from a connection to a remote host:

  • Confidentiality: You want to ensure that only the server and the device can read the data exchanged between the server and the device.
  • Integrity: You want to ensure that the data is not modified in transit - deliberately or not - and the receiver reads exactly what the sender sent.
  • Authenticity: The client wants to ensure that the server is actually the server they wish to communicate with, and not some third party impersonating the server.

HTTPS already offers you all of these, so adding a VPN on top won't improve things - at all.

The thing is, VPNs aren't designed to make connections secure - VPNs are designed to connect you to some remote network, as if you were part of that network. This works really well if you are, say, a company and wish to keep certain services available to your employees (who may be working from home) but not expose them to the general public.

4

If the web server is publicly anyway then there is no real gain in using both VPN and HTTPS. If one would like to not have the server publicly accessible then a VPN can add value. It restricts who can access the server to only authenticated VPN clients and thus reduces the attack surface of the server.

But as Z.T. already pointed out in his answer - a VPN can be an attack surface by its own. This is especially a problem since a successful VPN connection not only allows access to a specific service but to the whole machine and often also to the network connected to the machine. Additionally VPN services like IPSec usually run with high privileges and bugs in the implementation might result in serious system compromise. Contrary to this web servers typically run with reduced privileges which limits the impact.

A different option to reduce the attack surface might instead to restrict access by a firewall. This could be done by allowing only some IP addresses (if possible) or by employing techniques like port knocking or single packet authentication to allow only devices pre-authenticated by the firewall to access the web server.

Note that in some cases a VPN might be used not primarily as a protection layer but because the web server is deeper inside some internal network and could not be reached directly from the outside. But this has the already described problems regarding attack surface. There are alternatives to this approach though: instead of allowing access from outside to the whole internal network, only the internal application is exposed to the outside and also with an additionally limited attack surface. This concept is for example realized in products like ngrok, ZScaler Private Access or Cloudflare Access.

2

There is a rationale for this. The rationale is limiting the surface area that you expose to the internet. This is a term of art that means how much code can be reached by the attacker, if they are basically fuzzing you over the network.

The same way that if you are afraid of remote unauthenticated code execution bugs in your app then you don't expose the app to the internet, we can say that if you're afraid of remote unauthenticated code execution bugs in your HTTP server or TLS terminator then you don't expose it to the internet.

What do you expose to the internet that you would trust more than stock stable nginx with stock stable openssl? OpenVPN is definitely not more secure. IPSec is not more secure (it is a lot of code). OpenSSH might be more secure (use ed25519 keys or ed25519 ssh certificates), and you can use it as a tunnel, like a VPN, but I'm not sure it's worth it. For a sensitive internal server, it might.

The state of the art currently in 2021 is WireGuard. Its explicit raison d'etre is to have absolutely minimal amount of code that needs to be reviewed. Its design is such that the implementation is so little code you can review it in a single day (and people have done it). It eliminates handshake negotiation and associated state machine. It is an instantiation of the Noise Protocol Framework. It uses a single asymmetric primitive for KeX and Auth (Curve25519) and ChaPoly AEAD for all traffic. You can use a userspace implementation to essentially put a single app behind WireGuard, instead of putting a server behind WireGuard. Putting something behind WireGuard because you don't want to expose it to the public internet makes total sense.

3
  • The problem is that anyone with access to such a device can also gain access to the VPN. Even if you made per-device access, you can still just buy one of the devices to get access - or more likely, since they will all have the same credentials, just wait until someone buys them and dumps the credentials online.
    – user163495
    Feb 4, 2021 at 22:49
  • If they all have the same credentials this is completely pointless. If they have unique credentials injected at manufacture time, the server security team can blacklist or tarpit the credentials that are used by attackers to probe the server, by observing traffic a device would not send.
    – Z.T.
    Feb 5, 2021 at 6:36
  • Yes, you could do that - but given how much care and support current IoT devices have received, I would consider that wishful thinking.
    – user163495
    Feb 5, 2021 at 11:17
1

There can be a good reason but it's a niche that you are not likely to be dealing with.

If there is a need to anonymize the use of the IoT Device itself; for example you are operating in a country that bans using your IoT Device. A VPN could blind local monitors to the use of said device. Taken even further, a VPN could traffic shape to defeat traffic analysis as well.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .