10 ms·
Prediction: Wifi captive portal vendors will not react to this until after 90% of their customerbase has their funding dry up. It is incredibly common for publ
by protocolture 1y ago
Prediction: Wifi captive portal vendors will not react to this until after 90% of their customerbase has their funding dry up.
It is incredibly common for public wifi captive portals to be built on a stack of hacks, some of which require the inspection of HTTP and DNS requests to function.
*Yes better tools exist, but they dont arent commonly used, and require Portal, WAP and Client support. Most vendors just tell people to turn new fancy shit off, disable HTTPS and proceed with HTTP.
- GaryBluto 1y agoTo be fair, most people connecting to captive portal networks are more likely to be doing so on their phones, and I don't think IOS even allows non-Safari browsers for captive Wi-Fi login. I'm unsure how they'll fix this for Android though.
- protocolture 1y agoApple does however you have to go out of your way to do it. Every time.
- EGreg 1y agoWhat are you talking about? You can easily build the captive portals by setting up a custom DNS server, and HTTPS has nothing to do with it! In fact, local networks have been doing this very thing for years now. Apple even supports Detecting this interception so the operating system can show a captive portal to the user. The OS maker gives network admins an official a way to enforce captive portals, and it’s not going away with https.
- Maxious 1y agoYou can but many vendors have not yet adopted that
- protocolture 1y ago> 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 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/ 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)
- EGreg 1y agoBut 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.
- protocolture 1y agoSaves 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.
- kassner 1y agoHow do you tell iOS/Android which website to open? You do that by hijacking the request to http://captive.apple.com 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.