Hacker News Reader

Comment by hamandcheese | Hacker News Reader

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.

View on HN

Interestingly 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...

That 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.

Who has? They still need a valid cert for randomsubdomain.domainyoucontrol.com, how will they trivially get that?

The 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.

Ah, 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.

It 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.

How 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"?

You'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.

Why? 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.

If 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.

Yes, they can block me, but that's just annoying, not insecure. Intercepting unencrypted stuff is the reason for this whole thread. And if they change my computer's date, they might get one malicious cert working - assuming they can change it enough, since NTP has mechanisms for avoiding large leaps - but they'll break every single HTTPS connection besides that one, which I'm sure the user would notice almost immediately.

Meanwhile, routers are generally known to be insecure, and who knows how many viruses my guests bring onto my Wifi network when they ask to connect.

It could be configurable/disableable.

Reply on news.ycombinator.com