4 ms·
It would require you to run outside services to support it, but you could most certainly rig something together that lets each "installation" claim randomsubdom
by hamandcheese 9y ago
It would require you to run outside services to support it, but you could most certainly rig something together that lets each "installation" claim randomsubdomain.domainyoucontrol.com, phone home with the local network IP of the "installation", phone home the Lets Encrypt DNS-01 details, and then get a valid certificate for a domain that points to the local instance.
- saurik 9y agoThat is like, way way WAY less secure than just using an unencrypted connection, as now my requests are being alerted over DNS to some third party who has the ability to trivially hijack my connections off to the Internet at large.
- icebraining 9y agoWho has? They still need a valid cert for randomsubdomain.domainyoucontrol.com, how will they trivially get that?
- kuschku 9y agoThe owner of domainyoucontrol can simply rebind randomsubdomain and generate a new cert. There is no way to build a device with HTTPS that allows the user to distrust the maker of the device. Edit: before I get responses "you can never distrust the maker" — on HTTP I can audit the device, install it, and keep it in the local network forever, trusting it for decades. On HTTPS it needs to be online every 3 months, and the owner could very well intercept it at that time.
- icebraining 9y agoAh, the maker, fair enough. Still, there is, although not for free: the device can let you configure a subdomain of your own domain, and then use LE (with the DNS challenge) to get a cert. That still requires trusting your DNS provider, of course.
- kuschku 9y agoIt requires internet connection every 3 months, it requires trusting the DNS provider, and it requires having a domain. It'd be much better if DANE would already be supported, as the DHCP server can send you to a DNS resolver returning key info for local IPs, which in turn could use the corresponding certs.
- icebraining 9y agoHow would that protocol work? I'm not seeing how the DNS resolver would securely get the key info from the device. What if an attacker cloned the device's MAC and said to the resolver "hi, my new key is X"?
- kuschku 9y agoYou're in a LAN. You can not trust any device there anyway, and stuff like DHCP is unencrypted, and anycast anyway. Trying to add security in such an environment is... useless.
- icebraining 9y agoWhy? The whole point of authentication and encryption is to allow secure communications over insecure networks. So what if DHCP is unencrypted? If you have E2E auth/encryption, all a malicious DHCP server can do is prevent your communications, it can't spy or MITM them.
- kuschku 9y agoIf you have E2E auth/encryption, all a malicious DHCP server can is, indirectly, identifying every site you connect to, and potentially blocking you from accessing some sites. Or all. It can intercept all unencrypted stuff. This includes NTP, which in turn means your computer’s clock will be set wrong, which in turn means it can give you long distrusted certificates whose private keys have leaked. TL;DR: If you can MitM a system at the root, you can already break basically anything relevant.
- hamandcheese 9y agoIt could be configurable/disableable.
- fahrradflucht 9y agoInterestingly the german lawyers association build a software that does nearly this. Just with a small design change that made it a total flaw: To communicate out of a https secured web mailer to a local IP and Port where a security card reader driver would respond they registered bealocalhost.de which resolves to 127.0.0.1. To prevent mixed content errors they then shipped the private key for a https certificate for bealocalhost compiled into the card reader driver. Obviously after someone noticed that the cert got instantly revoked...