It’s about accepting that communication with the device is secure, not guaranteeing that the device itself is secure. In reality you don’t know if your bank’s servers are secure or if they encrypt passwords properly, etc, but you do know it’s them and your communication isn’t tampered with.
> could I impersonate that device on the local network?
Not readily with a device specific id check and TOFU (trust on first use) similar to SSH. If the device certificate was stored permanently for .local urls like `my-device-23ed.local`, then anyone who tried intercepting or MITM’img that device would have the user receive a message "warning device identity has changed, please check your device is secure ... etc " warning.
Not having any browser support .local certificate or identity "pinning" means that anyone who compromised your network (WiFi psk hacking anyone?) can impersonate a device you’d not know it. Browsers forget self-signed certs regularly, if they let you "pin" the certificate at all. A hacker can intercept the .local url (trivial) and use another self-signed cert. the user’s only real option is to blindly accept it whenever it happens. Then an intruder can MITM the connection to the device all they want. Is your router’s config page really your router? Who knows.
> Could I convince someone to accept a site on the wider internet as their IoT device? Someone smarter than me needs to think hard about these questions.
Any `.local` domain isn’t allowed to have a normal cert or global dns name. They could trick them on first use, but again with a device specific ID on first use it’d make that harder to do. After trust-on-first-use any access afterword wouldn’t be able to be tricked without a explicit warning to the user about changing device identity and that something funny might be happening.
If browsers implemented entering a device specific code as part of the "do you accept this device" on first use, that’d make it a much more usable and secure pattern. It’d standardize the pattern and encourage IoT shops do setup the device id checking properly.
To impersonate a device using .local certificate/identity pinning, a hacker would need physical access to the device to get it’s device id code, then hi-Jack the mdns request with the correct device specific .local address (on first use!), then setup a permanent MITM in order to impersonate a device. Otherwise the user would get a warning. Possible but serious resources required. With physical access you can modify hardware, possibly install a false cert on the user machine, etc, so security in that scenario would be largely compromised already.
Perhaps some IoT devices use custom apps and certificates but many just use http, or self-signed https. In my experience, IoT device makers have little experience with something like creating a CA. Getting users to install it would be a headache. Time is money on those projects and having an entire factory down because they can’t figure out how to install a certificate chain on Windows 7, well, most users will complain loudly. Currently IoT is full on IT-installing-certificate-chains, or no security at all. Many go with none at all therefore.
Therefore the current status quo with browser certificates on .local domains encourages far more security gaps and effectively makes it difficult for non-internet connected device to Operate securely without a fairly expensive and complicated IT setup.
No comments yet.
