←back to thread

.localhost Domains

(inclouds.space)
301 points todsacerdoti | 2 comments | 10 Apr 25 14:19 UTC | HN request time: 0.41s | source
Show context
mohsen1 ◴[10 Apr 25 14:49 UTC] 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 ◴[10 Apr 25 15:02 UTC] 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 ◴[10 Apr 25 15:14 UTC] 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. mohsen1 ◴[10 Apr 25 15:23 UTC] No.43644816[source]▶
Some more modern browser APIs only work in HTTPS. That's why I had to do it.
replies(1): >>43652385 #
2. jeroenhd ◴[11 Apr 25 10:35 UTC] No.43652385[source]▶
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.