4 ms·

I had a different (and imho, more pressing) argument for rejecting the "all-or-nothing" approach Google has taken towards HTTPS, namely that it actually punishe

I had a different (and imho, more pressing) argument for rejecting the "all-or-nothing" approach Google has taken towards HTTPS, namely that it actually punishes basically all non-enterprise intranet/lan devices using TLS/SSL because it makes them harder to access than if they only used HTTP instead [0]. The question that Google seemed to ignore (and still does) is "how do you expect a newly unboxed network device to ship with a non-self-signed SSL certificate?" The workaround some manufacturers have come up with is more repulsive than the original (There was one Chinese manufacturer that tried to get a signed certificate for a domain, then mapped that domain to 192.168.0.1 and shipped the private ssl cert w/ every router iirc. TP-Link has their own weird workaround where they give you a domain to log in to the router instead of the IP, and their router MITMs the connection and redirects to HTTP.) Google forcing everyone to HTTPS is one thing, Google forcing everyone to HTTPs and universally treating self-signed HTTPS connections as scams is another. [0]: https://neosmart.net/blog/lets-stop-punishing-iot-devices-that-embrace-https-shall-we/ https://neosmart.net/blog/lets-stop-punishing-iot-devices-th...

zokier 3y ago
in theory it would be neat to have dhcp option for acme server, which would allow automatic provisioning (short-lived) certs to lan hosts. basically all the building blocks are there
tialaramex 3y ago
The specific thing that Chinese manufacturer was doing wrong was shipping everybody the same private key, which means Mallory gets given Alice's key. This trick but for individual devices is fine, even recommended. But of course if the keys are each different that costs more than shipping devices which are identical...
SahAssar 3y ago
I've implemented https for IoT devices in a similar way that plex did it. Basically every device got a cert for *.$MAC_ADDRESS.myiot.com and then the DNS for myiot.com would essentially bounce back 192_168_10_10.$MAC_ADDRESS.myiot.com to an A record for 192.168.10.10 You needed to know the IP for the device still (in our case we still had a central service keeping track of it), but the principle works. For cheap IoT I guess the cost of the certs can be too large though, we couldn't use letsencrypt due to limits on the number of certs per domain.

zokier 3y ago

in theory it would be neat to have dhcp option for acme server, which would allow automatic provisioning (short-lived) certs to lan hosts. basically all the building blocks are there

tialaramex 3y ago

The specific thing that Chinese manufacturer was doing wrong was shipping everybody the same private key, which means Mallory gets given Alice's key. This trick but for individual devices is fine, even recommended. But of course if the keys are each different that costs more than shipping devices which are identical...

SahAssar 3y ago

I've implemented https for IoT devices in a similar way that plex did it. Basically every device got a cert for *.$MAC_ADDRESS.myiot.com and then the DNS for myiot.com would essentially bounce back 192_168_10_10.$MAC_ADDRESS.myiot.com to an A record for 192.168.10.10 You needed to know the IP for the device still (in our case we still had a central service keeping track of it), but the principle works. For cheap IoT I guess the cost of the certs can be too large though, we couldn't use letsencrypt due to limits on the number of certs per domain.