Can One-way SSL secure an IoT device?

Question

I am considering an IoT device connected to my local network (default settings, no VPN, no NAT, no DMZ) with or without Internet access. My device will run as a HTTP server offering a RPC mechanism with authentication and authorization. It advertises itself with mDNS and I talk to it using my mobile app or my RaspberryPi.

It seems that the norm in IoT development is to have mutual (two-way) SSL. Does that mean that one-way SSL cannot secure my trafic? Why?

Notes:

• I do understand the technical differences between one and two way SSL, I do not understand why is One-way (almost) never considered in IoT production.
• I understand having mutual SSL for a local device is difficult: you need to share server public key and cert to client and vice-versa. One-way, on the other hand, seems easier (does not require user action).
• Some mass produced devices like Philips Hue would rather have a local http endpoint open and unsecured than a one-way SSL encryption. Why would one make this choice?
• I expect this question not to be opinion-based. Apologies if this is the case.

Answer 1

SSL/TLS works well when the "server" is at known location (a fixed hostname) that can match the CN of the certificate it presents.

This doesn't work well for device on home networks (e.g. most IoT devices) because they tend to get IP addresses issued from RFC1918 blocks and do not have DNS entries. This means they can not be issued with certificates (well they can but most browsers will reject them). This is why devices like Philips Hue use unsecured HTTP endpoints of the device, they are basically relying on access to the network being secured to protect the device.

When mutual TLS is used it is for when the device is connecting to some central service, the client has it's own cert/private key to authenticate that it is able to act on behalf of the owner with that central server.

As a point of clarification to your question you do not need to distribute the servers cert/key to all the clients, just the certificate of the CA that issued the certificate is needed to prove the cert is trusted.

EDIT:

A good example of a secured local device connection is IKEA's Tradfri lighting which uses COAP over DTLS with a pre-shared key (in a QR code) on the device which is used to generate a per client key. This ensures physical access to setup a new client and protects data in flight on the local network.

Answer 2

Generally, TLS is good for much more than x.509, but many implementations limit it to only x.509.

x.509 is a technique for a secure indirect trust. "A" trusts "B", if "B" has a certificate, which is signed by "C" and "C" is trusted by "A". That works also in real life; you trust someone you don't know, if a letter is presented signed by a person you trust. Maybe you see the pitfall: if the letter says, please give a cup of coffee you won't give your car. Therefore the additional information in the certificate is also relevant to scope the trust. That's why a server usually has it's dns name or ip-address in it's certificate. Generally you may include different information (e.g. "living room lamp"), but many implementations are also at least preconfigured to use/check the DNS/IP stuff. And all that is only working if someone cares about the trusted "C's". Usually the OS or Application provider does this by updating the list of valid "certificate authorities". That's a lot of complexity, with implementations developed mainly for none IoT use-cases. Or who is going to update the list of valid "certificate authorities" on your device? I guess you will have to do it on your own.

If you can spend time in it, check your implementation, if it offers also PSK cipher suites. If not, maybe you can adjust the "validation check" of the servers certificate. But it requires a lot of reading to find a good solution. And sometimes the used TLS implementation just doesn't offer that.