Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CoffeeShopWifi.com – An HTTP website for connecting to guest WiFi

coffeeshopwifi.com

Post reply on HN
Print view View original

31–40 of 85 posts

Re: CoffeeShopWifi.com – An HTTP website for connecting to guest WiFi

#34

Post by moftz »

topher515 wrote: post #21
robbiemitchell wrote: post #10

I don't understand how this (and other similar sites mentioned) work. What is going on with the network that makes visiting a non-SSL site make it work? Anyone care to offer an explanation or have a link to one?

The way a captive portal works is that the router at the coffee shop sees your browser's DNS request for `google.com` and instead of responding with the real IP address for Google it lies to your browser and returns an IP address which it controls. If google.com were a non-HTTPS website then the router could simply then serve up any arbitrary content it wanted. i.e., it's own login/access form. However, since google…

You now also end up in the situation where your browser has the google.com certificate pinned so even if the portal tries to serve up a self-signed certificate for google.com, the browser will still complain about something fishy going on. The most complete solution is for the browser to try to detect captive portals and load up a plain HTTP website for the portal to hijack.

I remember in public school, IT had a website blocker that was effectively was a captive portal that would just route you to a "BLOCKED" web page and only could handle blocking non-HTTPS domains. Many sites were already going HTTPS by senior year so it was trivial to go to https://facebook.com and have full access. Another possibility was using a cgi-proxy. The site blocker was a blacklist so I hosted my own cgi-proxy when the one commonly used got blacklisted.

Re: CoffeeShopWifi.com – An HTTP website for connecting to guest WiFi

#36

Post by imwillofficial »

hartator wrote: post #14
pftburger wrote: post #12

Earlier quoted context omitted.

Yea I use this manually some times as well. Great for low bandwidth tests Just displays clean “success”

Clean "Success" sssSsss

I read this in the voice of Cobra Commander

Re: CoffeeShopWifi.com – An HTTP website for connecting to guest WiFi

#37

Post by yabones »

wyldfire wrote: post #27

Seems like the DHCPACK message and/or router advertisement could/should have a reference to the URI that has policy/billing form that's required to utilize a gateway. That way we don't need a special magical service that expects to be redirected to the policy form. AFAICT each OS/distro seems to solve this their own way currently, with their own service. Does any such standard feature already exist?

DHCP Options would probably work. They're most often used to provide clients with a default gateway and DNS servers, but they're also sometimes used to autoconfigure APs and thin clients as well.

https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Pro...

Re: CoffeeShopWifi.com – An HTTP website for connecting to guest WiFi

#39

Post by derimagia »

srhngpr wrote: post #8
ykat7 wrote: post #2

I like the straightforward explanation this site provides. That said, I tend to use http://example.com to trigger captive portals because it's an IANA reserved domain [1] that other people can't register. This gives me confidence to browse to it without fear that the domain could lapse in the future and get taken over (e.g. in a watering hole attack). [1]: https://www.iana.org/domains/reserved

Agreed - I always use example.com as well. Also worth noting that example.net, while not listed on the IANA page, is also reserved.

It's listed in rfc6761 which it references there.

https://datatracker.ietf.org/doc/html/rfc6761#section-6.5

> The domains "example.", "example.com.", "example.net.", "example.org." [...]

Post reply on HN