4 ms·
Captive portals really need to die. Fake DNS entries, URL redirects, injected html/javascript, false certificates, all are very annoying essentially train user
by furyg3 12y ago
Captive portals really need to die. Fake DNS entries, URL redirects, injected html/javascript, false certificates, all are very annoying essentially train users on bad behavior, and provide opportunities for nefarious actors (either by the hotspot provider themselves or attackers spoofing hotspots)
Plus the user experience is awful, sometimes when I join a network the portal shows up immediately, sometimes I only get it when I open a browser. Sometimes I open my mail first and get 10 error messages about incorrect certificates.
Is there any good alternative / standard that could serve the purpose without all of the current drawbacks?
- diafygi 12y agoCaptive portals are fine if you use a VPN. When I go on a flight, I visit a non-https site, get redirected to the WiFi login-or-pay, pay, and then connect to my VPN. All traffic after that (to the airline) is encrypted. Plus, airlines would never start blocking VPNs because you would lose all of your business customers.
- EvanAnderson 12y agoTry getting non-technical users to understand how to do that. Captive portals have been an unending source of frustration for my clients over the years.
- pdkl95 12y agoCaptive portals need to die not because of any technical reason - they have the same problem as the "UAC" pop-up showing up far-too-frequently: it teaches people to ignore what should be a serious security warning. A SSL certificate suddenly changing to a strange new signing authority is the kind of problem that should be a serious warning. By de facto teaching that it is ever valid to ignore important security measures, captive portals badly hurt the real education that needs to happen about how to handle computer security. Worse, this is another example of where laziness and convenience tend to promote these bad habits. Never-mind the average user - way too many technical people[1] fall into these bad habits - including programmers and sysadmins that really should know better. This isn't just WWW/HTTPS - did you always use a VPN? With a properly secure login that you know does not involve a MitM? [1] I mean in the general, statistical sense - any resemblance to people posing in this thread is an unintended coincidence. > never start blocking VPN That's easy - you just push PKI (alreadyd used in many places) and make up some excuse why this new version is needed for "airplane security". We live in an age where airlines (w/ the TSA/.gov) make a big deal about confiscating water bottles and regularly steal from luggage; do you really expect "business customers" to get angry over VPNs while allowing the past decade of security theater?
- mikecb 12y agoMaybe certificate pinning needs to include being able to forbid clicking through a warning. WiFi services would change their methods fast if they got sudden drop in users.
- acdha 12y agoIn addition to the obvious usability and cost drawbacks to that approach, it still doesn't help you with cache pollution. I've had to tell many people how to force a reload or even clear the cache because they got the captive portal response and it was never refetched after logging in.
- chasefox 12y agocaptive portals don't work with VPNs. A captive portal is simply a redirect to a login page for the purpose of authorizing a device to use a network. No VPN will work until the device has had a chance to open a web browser and pass through the captive portal. Once the device is approved to pass traffic through the network, the captive portal no longer plays any role. what gogo did was make some very poor decisions regarding proxying. in which case, yes, VPN can circumvent that.
- acdha 12y ago802.1x works for devices which already have an account – e.g. corporate networks, etc. This has been supported by Windows, OS X, etc. for many years. If you want the classic signup flow for a service where the user can't already be assumed to know about it, I believe you're talking about “Wi-Fi Certified Password” or “Hotspot 2.0” which appears to cover a slew of features related to devices discovering networks and being able to do things like detect which networks you have an existing roaming relationship with: http://www.arubanetworks.com/pdf/technology/whitepapers/WP_Passpoint_Wi-Fi.pdf http://www.arubanetworks.com/pdf/technology/whitepapers/WP_P... http://www.wi-fi.org/discover-wi-fi/wi-fi-certified-passpoint http://www.wi-fi.org/discover-wi-fi/wi-fi-certified-passpoin...
- chasefox 12y agoBut what about non-free hotspots? For example, captive portals are commonly used in hospitality to generate revenue. There needs to be a way to associate the device with a user for billing purposes. Captive portals provide this mechanism while making it easy for guest devices to join the network. Passpoint appears to provide a bypass for devices with a pre-existing, approved carrier; it does not appear to address the foreign/unknown device dilemma -- how to easily allow the unknown device onto the network and collect revenue from it.
- acdha 12y agoIt's not clear but the documents do specifically mention the ability to send people to login / signup pages. I'm pretty sure that's not being ignored so much as being buried in marketing/carrier-speak.
- chasefox 12y agoso.... a captive portal again. to clarify, I'm not defending what gogo did to SSL. That's wrong and horrible. but captive portals had nothing to do with it. edit: my reading of passpoint is that it provides a way for mobile devices to join wifi networks without making the user go through the process of selecting the proper SSID. Instead, the mobile device sees information about the network and joins automatically. but once the device is on the network, passpoint is complete and if the network is captive portal'd, the device will then have to visit the login page to proceed.