←back to thread

.localhost Domains

(inclouds.space)
301 points todsacerdoti | 3 comments | | HN request time: 5.041s | source
Show context
mohsen1 ◴[] No.43644362[source]
Avoid using `.local`. In my experience Chrome does not like it with HTTPS. It takes much much longer to resolve. I found a Chrome bug relating to this but do not have it handy to share. `.localhost` makes more sense for local development anyways.
replies(8): >>43644412 #>>43644418 #>>43644420 #>>43644480 #>>43644481 #>>43644511 #>>43644548 #>>43646934 #
Pxtl ◴[] No.43644548[source]
Honestly, if I had my druthers there would be a standardized exception for .local domains that self-signed HTTPS certs would be accepted without known roots. It's insane how there's no good workflow for HTTPS on LAN-only services.
replies(2): >>43644623 #>>43644673 #
jeroenhd ◴[] No.43644673[source]
Technically speaking you could use DANE with mDNS. Nobody does it, browser don't implemented it, but you can follow the spec if you'd like.

Practically speaking, HTTPS on LAN is essentially useless, so I don't see the benefits. If anything, the current situation allows the user to apply TOFU to local devices by adding their unsigned certs to the trust store.

replies(3): >>43644816 #>>43645208 #>>43646721 #
1. Pxtl ◴[] No.43646721[source]
> HTTPS on LAN is essentially useless

Public wifi isn't a thing? Nobody wants to admin the router on a wifi network where there might be untrusted machines running around?

replies(1): >>43652378 #
2. jeroenhd ◴[] No.43652378[source]
Sure, but you can connect those devices to a real domain and use Let's Encrypt on them, or you can TOFU and add the self-signed cert to your browser; after you've verified that you're not being MitM'd by one of those untrusted devices, of course (I dunno, by printing the public key on the side of the device or something?).

In practice, you probably want an authorized network for management, and an open network with the management interface locked out, just in case there's a vulnerability in the management interface allowing auth bypass (which has happened more often than anyone would like).

replies(1): >>43653764 #
3. Pxtl ◴[] No.43653764[source]
The former just aren't practical for small business and home consumers, though. Browsers just don't have good workflow for TOFU.

I agree on the latter, but that means your IoT devices being accessible through both networks and being able to discriminate which requests are coming from the insecure interface and which are coming from secure admin, which isn't practical for lay users to configure as well. I mean, a router admin screen can handle that but what about other devices?

I know it seems pedantic, but this UI problem is one of many reasons why everything goes through the Cloud instead of our own devices living on our own networks, and I don't like that controlling most IoT devices (except router admin screens) involves going out to the Internet and then back to my own network. It's insecure and stupid and violates basic privacy sensibilities.

Ideally I want end users to be able to buy a consumer device, plug it into their router, assign it a name and admin-user credentials (or notify it about their credential server if they've got one), and it's ready and secure without having to do elaborate network topology stuff or having to install a cert onto literally every LAN client who wants to access its public interface.