3 ms·
You are right in theory and in older times, but these days trying to get a browser to accept a self signed certificate is difficult. Remember that it would nee
by rogerbinns 10y ago
You are right in theory and in older times, but these days trying to get a browser to accept a self signed certificate is difficult. Remember that it would need to be done on a multitude of different platforms (eg Safari on iOS, Chrome on Windows) and by regular users. And no one is going to repeat this for the combinatorial explosion of browsers in the home with the devices (fridges, printers, other computers, device controllers, your garage door and what have you).
If you were a device manufacturer what would you do? One approach is to make all communication happen with "the cloud" as an intermediary, but that means that local operation is dependent on the Internet and some backend running on it somewhere. Or you have to come up with some hack, confusing instructions for users, lots of documentation etc. We see the results in Matthew Garrett's most recent post, and it isn't pretty.
- viraptor 10y agoI'm not saying it's a great solution. Just that it's not pointless to put a self-signed cert on a device like that. What I'd do as a dev manufacturer? I'd try to change the game entirely. The current system simply did not have devices like that in mind. One idea would be "device certificates" - basically known CAs that can certify MAC addresses. This should be enough for local networks.
- rogerbinns 10y agoI think we can agree that self signed certs aren't useless in theory, they are close to impractical these days especially for folks who don't even know what one is, and are confronted by scary warning dialogs (if you are even lucky enough to see one!) Amusingly mac addresses aren't as constant as you'd think. On my home lan I use a netgear wifi range extender. The way it works is to give fake (transformed) mac addresses for devices connected to it. For example if the real mac address is 11:22:33:44:55:66 when connected to the main access point, then when connected to the wifi range extender the rest of the network will see the mac address as aa:bb:cc:44:55:66. (The range extender also has ethernet ports - this affects wired and wireless connections to it.)
- viraptor 10y agoThat's why I mentioned local network. Once we extend that with bridges, of course the verification fails. You can also assume any mac you want, so that's not a good security at all. But that's all we've got. Unless we start integrating some kind of factory-sealed guaranteed-unique identity chips in all devices, there's simply no work around. Once something is on your network, you manage the identities. Either you have to manage some kind of CA, or trust whatever the factory provided you.
- rogerbinns 10y agoMy wifi extender is the local network. That is why I mentioned you can't even trust a mac address on the local network! I think this can be solved the same way plex did, by combining separate DNS space with a certificate authority issuing certs programmatically like letsencrypt does.