OK, and (1) how are you supposed to trust that the manufacturer won't get hacked one day (or whatever) and the IP address won't change to something external/malicious? (2) what if I don't have an internet connection and don't have a DNS server on the gateway that can reply to such a query?

1) If you trust them to write secure router firmware you can trust them to keep their HTTPS certificates safe - the former is a lot easer than the latter. 2) Router intercepts all DNS requests and responds with its own IP, responds to HTTP calls with HTTP 428, like already happens and like OSes already deal with appropriately.

> Actually, what if I have multiple of these routers in (say) a chain? I have to go physically find the one I need so I can connect an Ethernet cable to it and bypass all the others? I can't just connect to the one I want directly by its IP address?

Ah, I misunderstood, thought you were talking about a "captive portal"-type use case. If you're talking about having the router host some config interface like any other webserver then I'd say like any other webserver it should be able to generate its own certificate and CSR for a hostname you configure it with, and you submit that to your internal CA, or directly to let's encrypt or similar provider.

Er, what "internal CA" are you even talking about? Like imagine my grandma gets Comcast, her internet is not working, and I tell her to go to 10.0.0.1 to see if it shows anything. Suddenly she's supposed to get an HTTPS error warning her there's an MITM attack? Or am I supposed to tell her to install a root cert in her machine and every other machine she might connect in the future?

Or heck, what if I'm just connecting to my damn scanner in my network? Or what if it's a guest trying to do that? "Sorry auntie, you'll have to install my self-signed cert as a root cert before you can use my scanner's web interface to scan your pic"?

If your router or scanner is to be accessible over the network then it needs its own name and it needs to be able to certify that that's its name. Anything else is just too dangerous. A user expects addresses they enter into the browser to mean the same thing on any connection; having a few "magic" addresses that go one place on one network and another place on another network is a recipe for users getting hacked.

For the consumer use case, maybe the router gets a unique default address in the manufacturer's namespace (router12345.linksys.com) and ships with a certificate for that name and that name printed on the box, just like we do for the admin password. Since it's a router it's probably running the DNS for your network (at least in the consumer use case) so it can route requests for itself correctly. For scanners or similar, the router would need to update its DNS when the scanner joins the router's network - a lot of routers already do this within the local domain based on DHCP registrations, so this ought to be simple if it's not already done. Crucially this part isn't security-critical - if you try to print a confidential document on your network printer while you're on your neighbour's wifi, the worst their router can do is not route you, because an evil endpoint won't have your printer's certificate.

> If your router or scanner is to be accessible over the network then it needs its own name and it needs to be able to certify that that's its name. Anything else is just too dangerous. A user expects addresses they enter into the browser to mean the same thing on any connection; having a few "magic" addresses that go one place on one network and another place on another network is a recipe for users getting hacked.

...a recipe for users getting hacked? on a home network? by whom exactly? my family? The router is already firewalling the entire network against the internet. Can you describe the exact attack scenario you're imagining?

User tries to print a confidential document. Prints it on their neighbour's printer, or a printer somewhere on the internet, instead.

User tries to grant their soundsystem access to their google music. Gets cut off and asked to reconnect as they're walking out the door. Ends up granting the cafe's soundsystem access instead, and maybe that gets combined with another exploit to give someone else at the cafe access to their documents.

User is in the habit of using the same username/password everywhere, enters it into http://192.168.1.1 on some hostile network.

User knows to use a password manager, but password manager is happy to put their router password into some other router's login; attacker uses this to subvert their router

Thief replaces the home webcam with one that supplies a dummy image, takes their time to clear the place out.

You're not describing the attack, you're describing the damage that could be done after an attack has already compromised the system. I'm saying describe the exact attack scenario, i.e. how any of these could be made possible in the first place.

Impersonate popular home devices on public wifi networks, or on the Internet. Exploit that "push the button on the router to allow this device to join" thing that was popular (but vulnerable) a few years ago. Subvert an insecure IoT device on the target's network. Attack from their friend's compromised device when they connect to the target's wifi, or just use their credentials. Splice into ethernet cable where it runs through a maintenance floor or a cabinet on the outside of the building. Once you're on the network either ARP spoof or just register with the router under the same name (perhaps after DoSing the legitimate device).

The network is not completely public, but even a home user's network is too weakly-defended to just blindly trust to any device connected to it.

Can't the router reply to the DNS request itself with 192.168.1.1?

The public DNS record is needed to verify the DV cert, not to do the actual lookup.

Great, now what happens when I reconfigure my router to use 192.168.0.x IPs? Or 10.0.0.x? Or any of the millions of other possible options?

It's trivial to support the most common alternatives. Seems harder to add arbitrary support.