We could change the standards to facilitate client apps using a private network's own PKI. This would solve about a million problems that currently exist with most private orgs that need to enforce policy on content on secure networks, as well as allowing consumers to securely browse self-hosted private services. I don't know what that would look like or what would need to change, but it could definitely be done.
Ideas:
1) An extension to PKI that browsers support. If you browse a service with a certain type of cert on a certain TLD, a) it won't work except on private networks, b) it will prompt the user to enter a key, such as a key printed on the backside of a router (this is already used to get consumers onto WPA routers, so we know it's reasonable). The device with the cert creates the cert itself. If the key is right, you can browse the service, and your browser caches the key with the cert. If an attacker learns the key they can try to make a new fake cert, but the browser would know it's not the same as the old cert and block it. Replacing these should be quite infrequent, as often as people replace their home network devices.
2) A TLD that browsers will only ever respond to if its names resolve to private address ranges. If a service wants to serve HTTPS privately, it will request a cert be signed by a device that is auto-detected on the local network. The device will return signed certs for a particular host on the local-only TLD. The device can have any logic it wants to restrict what can get a cert and how. The trick is how to make the client trust the device, which I think 1) would solve. This device can, for example, only ever create a given FQDN's cert once; if an attacker tries to generate a duplicate, it will fail. If the cert ever needs to be refreshed, the memory/flash of the device needs to be reset. This makes it possible to have a captive portal request a cert from a local router, and no attacker can generate an identical cert unless the router was reset and they triggered the cert generation before the captive portal did. (Also for captive portals, the admin of the router could just hard-code what clients could request what certs, so the captive portal could always request particular local certs for itself, while no attacker could). It's still tricky to determine trust on first connection in the case of things like coffee shops, but maybe you could receive a public key via WPA or something (then again that's kinda kicking the can down the road to WPA)
Ideas:
1) An extension to PKI that browsers support. If you browse a service with a certain type of cert on a certain TLD, a) it won't work except on private networks, b) it will prompt the user to enter a key, such as a key printed on the backside of a router (this is already used to get consumers onto WPA routers, so we know it's reasonable). The device with the cert creates the cert itself. If the key is right, you can browse the service, and your browser caches the key with the cert. If an attacker learns the key they can try to make a new fake cert, but the browser would know it's not the same as the old cert and block it. Replacing these should be quite infrequent, as often as people replace their home network devices.
2) A TLD that browsers will only ever respond to if its names resolve to private address ranges. If a service wants to serve HTTPS privately, it will request a cert be signed by a device that is auto-detected on the local network. The device will return signed certs for a particular host on the local-only TLD. The device can have any logic it wants to restrict what can get a cert and how. The trick is how to make the client trust the device, which I think 1) would solve. This device can, for example, only ever create a given FQDN's cert once; if an attacker tries to generate a duplicate, it will fail. If the cert ever needs to be refreshed, the memory/flash of the device needs to be reset. This makes it possible to have a captive portal request a cert from a local router, and no attacker can generate an identical cert unless the router was reset and they triggered the cert generation before the captive portal did. (Also for captive portals, the admin of the router could just hard-code what clients could request what certs, so the captive portal could always request particular local certs for itself, while no attacker could). It's still tricky to determine trust on first connection in the case of things like coffee shops, but maybe you could receive a public key via WPA or something (then again that's kinda kicking the can down the road to WPA)