Hacker News Reader

Comment by andy_ppp | Hacker News Reader

I am slightly worried that a lot of public Wifi seems to be unable to redirect you to the login page (think Starbucks) if you visit https:// sites. The Guardian was my go-to for such situation so that I could login and get online.

I'm not sure how these redirects work (DNS? Inserting JS into the page?) but it seems to be a common problem.

View on HN

http://neverssl.com/

They usually work by MITMing your connection to whatever site you're trying to visit and serving an HTTP redirect (maybe 307?) to the captive portal page.

As a substitute for The Guardian, maybe try http://example.com?

But eventually all the sites will be HTTPS - I've no idea what non-techy users do when faced with this apparent brokenness.

I’d be surprised if example.com goes https-only. Regardless, if all sites go https only then free wifi providers will have to come up with some other way of redirecting you to their signup page.

There seems to be some protocol by which operating systems automatically launch the login page upon connecting to the WiFi network. Unfortunately, it seems to fail pretty often and probably doesn't work for bridged connections.

There's no standard protocol in widespread use. Typically operating systems attempt to fetch a known resource when connecting to a new Wi-Fi network, and if it redirects, then they treat the destination as the captive portal sign-in page and display it with special chrome / modally. The URL each platform attempts to load varies by vendor and version.

Do you have any links to resources or know what name(s) people use when talking about this strategy? I'd be interested to know which URL Debian attempts to fetch, but I'm not sure how I'd even begin to search for the answer.

"Captive portal detection"

And here's your answer: http://network-test.debian.org/nm

Thanks!

cf. http://blog.erratasec.com/2010/09/apples-secret-wispr-reques...

My understanding is that this is just the OS trying to fetch a known page over HTTP and, if redirected, assuming it got a login portal and presenting it to the user.

I assume this can continue "working" (with your noted caveat that it doesn't even always work today) forever, as the process that checks doesn't need to understand HSTS or to ever try HTTPS, regardless of what actual web browsers start doing.

Basically, they try to phone home and if it redirects, they assume it's a captive portal login page. It's a sort of controversial practice, because it means that the OS vendor now always knows where and when you're accessing the internet.

On Nougat it seems to work flawlessly most of the time. I wonder what the protocol is. Maybe a request to the access point's DNS server to see what IP is returned and then connect to that?

Ran into this with Southwest's wifi this week. HSTS preloading makes it worse too. No dice with Google, Facebook, my website, etc. Just lots of error pages until I figured out what was going wrong.

In-flight wifi on United has solved this problem by giving you an explicit page to go to. They say to go to unitedwifi.com to activate the connection.

If you go to the Starbucks website the Accept Terms Of Service redirect seems to work fine... that's what I've usually done anyhow (shrug).

Starbucks.com is https and I'm pretty sure it didn't work in Japan. YMMV.

ha, American here and I use usatoday.com for that. But neverssl.com is great find.

Reply on news.ycombinator.com