
Let’s stop punishing IoT devices that embrace HTTPS - captaincrowbar
https://neosmart.net/blog/2017/lets-stop-punishing-iot-devices-that-embrace-https-shall-we/
======
deathanatos
Just because it's an IP address in one of the private LAN ranges does not
imply that the connection isn't being MitM'd, and it definitely doesn't imply
that you're talking to who you think you're talking to. (How do I know I have
the _right_ 192.168.1.42? Am I on the "right" WiFi?)

The actual thing that TLS certificates set out to verify — that you're talking
to who you _think_ you're talking to — is simply not possible against a
private LAN IP address.

(As an aside, I feel like it's entirely possible, _technologically_ , to give
IoT stuff unique DNS names, and thus, actual HTTPS. The problem is social,
boiling down to the quality of the software we use. Consider: a machine, say
an IoT device uses IPv6 (this is needed to get around NAT, since NAT won't
work with the next bit). It can determine its hostname via a reverse DNS
lookup on its IP address, and then, with ACME, get a certificate for that
hostname. Now, it's not a pretty hostname, but nothing prevents ISPs from
issuing better hostnames except a lack of imagination. E.g., I could be
deathanatos.giant-isps-customers.com, my machines, machine1.deathanatos.giant-
isps-customers.com, etc. Heck, the ISP could essentially delegate me that DNS
space, or even allow me to set the reverse IP address record to point to my
own DNS name that I pay for. I'm not 100% certain if it's entirely foolproof,
but you could also envision a protocol for devices to allocate a subdomain
under the customer's domain. But again, this will all never happen.)

