Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Aside from custom root certs being installed, https is out either way, not only with IP address, right? HSTS makes that even more of a problem, and pinning makes even the custom root cert a problem. Captive portals seem like an increasingly fragile idea, except that OSes increasingly intervene appropriately.


State-of-art for captive portal handling is:

Step 1) For mobile device to make a request to a special URL that is known to respond with short 200/204, something like that:

  http://clients1.google.com/generate_204
  http://captive.apple.com/hotspot-detect.html
  http://www.msftconnecttest.com/connecttest.txt
...and bring up UI (sandboxed browser) if anything else than expected short 2xx was received.

Step 2) Mobile device reuse same cookies for the same portal second time around, so portal can recognize returning user and let them in without annoying with login prompt each time.

Assuming mobile device has a separate cookie jar for this, and captive portal is HTTPS with proper certificate, and doesn't try to break other people's SSL, that is pretty secure. Sure, this is not the most efficient protocol, but up-side is - it's open-ended. You can fit here anything from "press here if you agree to behave" to complete walled garden like hotspot on a train that shows you interactive map, schedule and transport connections available on the next stop along with small banner asking $1 for full internet access.


Keep neverssl.com in your pocket when you encounter one of these older captive portals that try to redirect Google and you see and HSTS error.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: