[marcosdumay]

That's a thing for local software to decide.

It's also something that can be done with a level of reliability that will impress incredulous people. But that there will always be somebody to complain that is not following the standard recommendations.

[0xbadcafebee]

In that case you don't need a certificate. Just check that the .local FQDN's IP is on a local network.

  1. Look up all local interfaces' networks (IP & subnet mask)
  2. Determine if .local IP is within subnet range of one of the interfaces
  3. If .local IP is not on a subnet of a local interface, drop the connection

This is still "host-based networking" and there's always the possibility a rogue network could be attached to your host, such as a spoofed open access point, or an ISP with lax network security and a customer on the same subnet being attacker-controlled.

What certs prove is "this host currently has a private key and cert, and at one time this private key was used to generate a CSR for this cert, and at one time it was validated that an IP resolvable by the domain name in the CSR was also controlled by whoever issued the CSR". It's a very awkward thing that doesn't really match up to local consumer devices.

We need a vendor key registry, the way MAC address prefixes are mapped to vendors, so at least we could say "the key on this host came from vendor XYZ". The browser would need to pop up a warning saying "WARNING: You are now connected to a local device from Vendor XYZ! If you did not intend to connect to a local device, close this window!" Updates to the vendor registry could also invalidate previous entries if old keys got compromised. But this would be in combination with the aforementioned "is the site on a local network?" logic. Anyone using a .local would have to both compromise a local network and steal a key from a vendor, or be registered as a vendor, and then the user would have to be dumb enough to click through a big warning about a local device.

[renonce]

It's not practical to hide vendor keys. Unless the key is embedded in a security chip in factory it's usually possible to extract them from the firmware. Even if vendor CA is not compromised, stealing keys from a single device should be sufficient.

[0xbadcafebee]

I was thinking more along the lines of signature verification, but I forgot that any spoofed device could just supply a signature it got out of a device, so I think you're probably right.

[BizarroLand]

I wonder if the router or switch could be set to provide that information? Most modern routers have LAN info and could reliably inform a smart enough appliance that it is accessing something inside of the gateway address.

[marcosdumay]

Indeed that's much better.

It's probably better if we terminate the trust at a TLS certificate or something similar to DANE. So there isn't any specialized registry to maintain.