> Apple even supports Detecting this interception so the operating system
Whats it intercepting? Apples detection sends a HTTP/HTTPS request to captive.apple.com. If it fails, it assumes a captive portal. Theres also a DHCP option apple supports.
But even after detection, theres redirection.
Have a look at WAP Vendor options.
Heres Powerlynx explicitly requests disabling HTTPS before auth on Cambium in their user setup guide.
https://docs.powerlynx.app/networking/cambium.html
"Redirect HTTP-only - On"
This guarantees that, upon redirection, you are presented with a HTTP login page for the captive portal. And then any subsequent redirections, also have to be HTTP.
Heres Start Hotspot
https://go.starthotspot.com/help/cambium/
"Redirect: Tick HTTP-only"
Cambium supports more modern methods, but captive portal vendors are not going to shift before letting their customers fall on their face.
(Also, cambiums guest access whitelist is based on DNS and breaks with DNS over HTTPS/TLS)
But why do we need to avoid https at all? You can easily have CA-signed certificates and have DNS server resolve the local ourfreewifi.com domain. It’s your domain, you can even set up DNSSEC and it will be fine.
Saves the hotspot portal vendors headaches in debugging. Yes they could (and will be dragged kicking and screaming to do so) just use proxies with certs to intercept traffic but in the short term if they can avoid good practices they will.
How do you tell iOS/Android which website to open? You do that by hijacking the request to http://captive.apple.com and then 301/302 it to your domain, with or without https. If the first request iOS made was to be secure, you’d have to have a valid certificate for captive.apple.com running in your infrastructure OR the iOS would have to allow self-signed without asking for exceptions. Both sound like a terrible idea.