> Surely we are past this bullshit now thanks to https being everywhere?
Plenty of hotels (and other places) misdirect your DNS queries so that your machine will connect to the hotel's captive portal where you need to accept the terms and conditions for using the wifi. This causes HTTPS connections to fail. Captive portals are a rather inelegant hack, but in most cases they achieve what they are designed to achieve.
But once you're past the portal (even if you need to manually load example.com so you actually see it without hitting cert pinning errors), TLS gives you back the "can't touch this" you want.
Yep, and more and more OSes and browsers detect this situation and propose you a button to go to the portal. At least for me, both KDE and firefox have their mechanism for this.
It still breaks a lot of stuff (notably, the Nextcloud client) as long as you are not logged on the captive portal, but well…
Android, iOS, and windows also have this functionality. It's a shame there hasn't been a widely implemented standard for captive portal things yet. Even if what we have now works alright if you're doing web things.
> Plenty of hotels (and other places) misdirect your DNS queries so that your machine will connect to the hotel's captive portal where you need to accept the terms and conditions for using the wifi.
And for all the whining about how "but DNSSEC doesn't do anything!", this is exactly an attack scenario which DNSSEC protects, and which it has protected since the very first RFC describing it. The client can check for itself whether the IP address in the response has been correctly signed by the (sub-)domain owner (and recursively whether the (sub-)domain has been signed by the parent domain, all the way back to the root).
As for "but how will I redirect hosts to my captive portal?", that's what DHCP option 114, DHCPv6 option 103 and IPv6 Router Advertisement option 37 are for. https://developer.apple.com/news/?id=q78sq5rv
If the network’s owner was the one doing DNS redirects, couldn’t they just instead use the IP address in the DNSSEC-signed record themselves? I don’t think DNSSEC is a robust protection if you don’t trust the network you’re connected to.
The attacker doesn’t resign the DNS record with their own key, they just let the legitimately signed record though and use the IP address in that legitimate record themselves. If someone owns the network (or is an active MitM) they can control where IP addresses route to.
Plenty of hotels (and other places) misdirect your DNS queries so that your machine will connect to the hotel's captive portal where you need to accept the terms and conditions for using the wifi. This causes HTTPS connections to fail. Captive portals are a rather inelegant hack, but in most cases they achieve what they are designed to achieve.