I’ve been working with Ruckus WiFi Access Points quite a bit recently, both in the “Unleashed” mode (one of the APs acts as the “controller” for the other APs) and with the standalone ZoneDirector controllers. It’s nice equipment with good RF performance, but the documentation is somewhat dated – particularly everything dealing with guest access that’s gated with a captive portal. So recently I opened what I thought would be a quick/simple ticket with their support folks – given how much has changed just in the last decade, I wanted to find out what their current recommendations are.
In theory, the captive portal work like this… You walk into your favorite mom & pop coffee shop, open your laptop, connect to their wifi, and when you type some URL in your browser (Facebook, Google, Twitter, etc.), you’re magically brought to a sign-in page. You might just be asked to agree to some “Terms of Service”, or to supply an email address, or even enter payment info. Once you’ve done what’s asked of you on the sign-in page, you’re sent on to your original destination. Fast-forward to today and most of that is basically broken. All major sites use https, all major browsers try to protect you from sites spoofing other sites, and most of your frequently-used sites in your browser history will autocomplete to the https version of a site.
What’s happening here? Well, the AP you’re connected to is intercepting your request for whatever website you’re trying to visit and issuing a temporary redirect to it’s own IP, and then possibly to an externally-hosted login page (this is my use case). Once you are authenticated, the AP stops redirecting your web requests and instead you are now able to reach your intended site directly. This all worked great in the pre-HTTPS days…
So in reality, what happens if your OS does not have a clever way of doing this, or you annoyedly dismiss the pop-up window from the OS, is that you are presented with a series of scary browser warnings about mismatched SSL/TLS certificates, unsigned TLS certificates, etc. on each redirect. If you click through all of them, you’re given the opportunity to sign in, agree to the Terms of Use, etc. and finally use the internet.
On the Apple side of things (OS-X and iOS), there is a nice workaround. At the OS level, when a network is joined, the OS tries to reach “http://captive.apple.com/hotspot-detect.html”. If the OS can reach that AND the content it expects is there AND the HTTP status code is 200 (as opposed to 301 or 302 which would indicate a redirect), your device assumes it has internet connectivity. Behind a captive portal this will fail. In practice, this means that pretty much as soon as you connect to that cafe hotspot, the OS will pop up a small window with the captive portal’s login page. This little mini-browser has tried to fetch the captive.apple.com URL and received a 301 redirect (and possible further redirects) and made it to the login page. You enter the required info and that’s that.
Windows seems to be different – Windows 7 apparently shows a notification in your systray that instructs you to manually open a browser to finish connecting (which may or may not lead to a series of SSL/TLS warnings), Windows 10 reportedly shows its own login box, which truly confuses people. Android seems to do similar things. If I ever have the opportunity to test on these platforms, perhaps I’ll add more details here, but basically the Apple option is the easiest for normal humans.
So, back to my support ticket. The helpful Ruckus support person stated that the following happens when a new wireless client connects to an AP/SSID with the captive portal enabled:
- Client makes a DNS request for whatever page the user is requesting
- Ruckus AP/controller intercepts DNS request and instead of returning the correct IP for the site being requested, it returns the IP of the AP (Unleased) or controller (Zone Director). More on this step later…
- Client requests whatever page the user was looking for, but to the IP the AP/controller returned
- AP/Controller issues a 302 redirect to either its own captive portal page or an external portal page
- Client logs in at that page (after ignoring SSL/TLS warnings)
- AP/Controller issues another 301 redirect to the original site the user requested
The DNS part sounded odd so I started Wireshark on a laptop and flipped over to a guest network with captive portal. The support guy was mostly correct, but the DNS part was not. I saw no evidence that the AP/controller was touching DNS at all.
On OS-X, the sequence looked like this:
- Network interface comes up and DNS request for “captive.apple.com” is made and the proper/real IP for this is returned.
- An http request for http://captive.apple.com/hotspot-detect.html is made to the real IP for that hostname (note that this is not an https URL!)
- AP/controller spoofs a reply from the captive.apple.com IP and the reply is a 302 redirect to the AP/controller’s actual host address
- Client follows the redirect
- AP/Controller sends another redirect to external captive portal page
- Client follows the redirect, displays login page
- Login, and close captive portal assistant window – done and online
If I ignore or close the OS-X captive portal, then the sequence is identical if I know enough to point a browser to a non-https site. That’s not a common thing though with most sites defaulting to https. So in that case, the process is the same as above, but with a warning for mismtached cert at every step. As best as I can tell, the Windows or Android experience is similar.
So did I find what I wanted? Yes. My action plan for any client using this sort of captive portal would include the following:
- Setup a non-https site on some subdomain – like http://fixme.example.com/ – make it known to the helpdesk and ask anyone with problems joining the guest wifi visit that URL in a browser. Lacking https, the portal should work seamlessly.
- Educate helpdesk staff on all of this, give them the above as the fallback should all else fail
- Set a hostname on all Zone Directors so that URLs generated by the ZD in this process have a hostname under one of the client’s domains
- Take that list of hostnames for all ZDs and buy the cheapest SSL/TLS cert available – this does not fix everything, but it eliminates one or two SSL/TLS warnings in the login process. It also gives you a nicer looking URL with the company’s name in it somewhere
- Not an action item, but note that the DNS redirect just is not a thing that happens.
Lastly, the first and only DNS request and answer for “captive.apple.com” – clearly not spoofed/altered.
