.localhost Domains

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.

Actually, MacOS gives your computer a .local domain on DHCP and Bonjour usually

if you add your CA to the list of trusted certificate, everything will be fine. I do not recommend using custom certificates and would stick to http, unless you really know what you are doing

I use .local all the time and it works just fine. For TLS I use my existing personal CA, but HTTP links don't cause issues for me.

That said, I do use mDNS/Bonjour to resolve .local addresses (which is probably what breaks .local if you're using it as a placeholder for a real domain). Using .local as a imaginary LAN domain is a terrible idea. These days, .internal is reserved for that.

.local is mDNS/Rendezvous/Bonjour territory. In some cases it takes longer to resolve because your machine will multicast a query for the owner of the name.

I use it extensively on my LAN with great success, but I have Macs and Linux machines with Avahi. People who don't shouldn't mess with it...

The reason is .local is a special case TLD for link-local networking with name resolution through things like mdns, by trying to hijack it for other use things might not go as you intend. Alternatively, .localhost is just a reserved TLD so it has no other usage to check.

https://en.wikipedia.org/wiki/.local

https://en.wikipedia.org/wiki/.localhost

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.

It’s actually gotten worse, you need to run a CA or use a public domain where it’s easy to get your internal naming schemes in a transparency log.

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.

The easy workaround I've seen companies use for that is by using a basic wildcard certificate (*.local.mydomain.biz).

Some more modern browser APIs only work in HTTPS. That's why I had to do it.

Browsers won't use http2 unless https is on — chrome only allows six concurrent requests to the same domain if you're not using https!

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

I recommend using the .test TLD.

* It's reserved so it's not going to be used on the public internet.

* It is shorter than .local or .localhost.

* On QWERTY keyboards "test" is easy to type with one hand.

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

Modern browsers only enable those APIs because of security concerns, and those security concerns aren't lifted just because you're connected locally.

The existing exception mechanisms already work for this, all you need to do is click the "continue anyway" button.

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.