CoffeeShopWifi.com – An HTTP website for connecting to guest WiFi | Hacker News Reader

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

coffeeshopwifi.com

133 pointsjastr83 comments

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." [...]

iOS (and macOS?) use http://captive.apple.com/

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

Mozilla also has one that Firefox will use when detecting captive portals: http://detectportal.firefox.com/success.txt

I like neverssl.com, it's a nice basic text page.

I've used this on Linux as well.

That means apple.com cannot be HSTS preloaded, which is too bad for security.

I also use example.com, and unfortunately https://example.com/ also works, so if you just type "example.com" in to your browser, you are likely to hit the https:// URL first and get an error. And you have to type the entire "http://example.com" out, or your browser's auto-complete will go for "https://example" first. And even when it's http://, a captive portal may redirect you to an internal https:// site without a valid cert. And sometimes it caches so you need to remember to Shift+Reload.

The most infuriating thing about technology is how it reminds me how incompetent we are as a species. Here we are, the global collective of Information Technology workers, captains of industry, cutting-edge entrepreneurs, and white beard pros, and we cannot make a god damn computer just connect to a coffee shop's network without jumping through a bunch of annoying hoops, like the whole system was constructed by an intern on summer break. (No offense to interns)

Simple answer: We can make it connect just fine, but we either need to give up on value extraction (i.e. "pay a fee to connect"), or on security.

Captive WiFi fundamentally relies on intercepting all Internet traffic to send you to the captive page. That's only possible with fake certificates, because you want to provide a response on behalf of the website the user wanted to go to. This wasn't originally part of "how the Internet works", because "pay as you go" just wasn't considered during the design.

But... we've solved that problem. rfc8910 does specify how you can use DHCP to work around that. Except, it doesn't work for legacy clients. So those will still be supported in existing setups anyways.

And since everybody's supporting legacy setups, the incentive for any single provider to even implement the new method is about zero.

The whole mess is a result of replacing the engine while flying the airplane, in an environment optimized for rent seeking behaviors. We can do the right thing, but we choose (collectively) not to spend the money.

I'm not sure how example.com is better than any other domain in a coffee shop setting. Any DNS lookup can be made to resolve to any arbitrary IP address, so it would not matter if a domain is lapsed or even real.

It's a lot easier to simply register a domain like coffeeshopwifi.com if/when the owner abandons it and wait for the requests to pour in, than it would be to find the specific coffeeshop that your target frequents and then compromise their DNS servers.

It is not about compromising DNS servers at coffee shops.

If I go to a coffee shop, do any packets even have to go to coffeeshopwifi.com or example.com at all?

1. DHCP happens.

2. I type http://example.com, but I get 'Please click AGREE etc. for WiFi'. So far, this should all be internal to the local network.

3. I click on AGREE, but my browser actually goes to philzcoffee.com

I have always used http://http.rip

Similar to http://neverssl.com/ I guess?

awfully similar :)

I have "HTTPS-Only Mode" on in FF, and it connects HTTPS to CoffeeShopWifi.com but not to http://neverssl.com

Most people won't have HTTPS-Only Mode on, and those that do probably understand the issue, but if FF changes settings in the future this could be a problem.

I believe http://wifi.yt (you there?) predates most of these.

Ah, the old MySpace argument.

Yeah, and neither seems to work for me on iOS for some reason.

Like right now, with a connection, it works as expected (loads page, shows security warning in address bar)

But if I don't have a connection, it seems like either the browser or lower level OS security features (ATS?) force the device to try https first, which of course hangs/fails.

A huge pain in general.

My favorite version of this trend remains http://alwayshttp.com because https://alwayshttp.com doesn't work since alwayshttp.com:443 doesn't connect.

On the other hand, it's possible to reach https://coffeeshopwifi.com and (with a cloudfront certificate error) https://neverssl.com which makes me wonder if something in whatever I'm using is trying to upgrade to HTTPS when I fail to reach them.

httpforever.com is the one I use. https connection gets redirected to http to ensure that it gets captured.

I think you're misunderstanding the GP. The HTTPS connection will not be redirected when you are behind a captive portal, you'll receive an invalid certificate error (when the captive portal tries to serve itself at that address) or the website will simply not respond. Only if the HTTPS response is cached in your browser would the redirection work behind a captive portal.

You’re 100% right, thanks for the correction.

Huh, I don't even get a certificate error on https://coffeeshopwifi.com/ - and I got automatically upgraded (I guess due to https everywhere) haha

Browser extensions will redirect HTTP to HTTPS as the request is made, so CoffeeShopWifi can't help you there.

Most sites will send a redirect to HTTPS, which CoffeeShopWifi does not.

So I decided it's safe to make a cert and support HTTPS.

> Browser extensions will redirect HTTP to HTTPS as the request is made, so CoffeeShopWifi can't help you there.

They could stop serving port 443. That would prevent any extensions from automatically upgrading.

Getting "you had one job" vibes here.

That is why I use x.com also has a very shall payload

It's actually a moderate pain to set up something that doesn't answer on port 443 unless you want to host it yourself. I tried with http://wifi.help, but it's at Cloudflare and I don't know of a way to block port 443 without paying for their WAF.

http://captive.apple.com/ is pretty much always up because it has some pretty strong infrastructure behind it since billions of Apple devices connect to it automatically. It's always my goto for captive portals.

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...

There are some RFC7710 and 8910 come to mind.

I think the proper solution for this is to just stop doing captive portals. They suck, they break easily, no one ever reads what they say, and while I'm not a lawyer I question their value from a litigation perspective.

http://www.neverssl.com

I use http://perdu.com/

It says:

    Perdu sur l'Internet ?
    Pas de panique, on va vous aider
    
        * <----- vous êtes ici

Translation:

    Lost on the Internet?
    Don't panic, we are going to help you
    
        * <----- you are here

It is funny, it's been up and without change for decades (amazingly; first snapshot on archive.org in 1998, Wikipedia reports it's been there since 1996!), never had a https version, never noticed a downtime and I've yet to see a page that combine such a short / easy to type URL with such a short size (only 163 bytes, which is useful on spotty / weak connections).

Hard to beat.

CoffeeShopWifi.com is certainly a good idea, could be added to the favorites of non-technical English speakers. Coffee shops are not the only places with captive portal though, here in France they are common on Wifi access points provided by ISPs to their customers when they are roaming, and by the train company (SNCF) in trains and train stations.

Captive Portal is probably too technical so naming this is hard.

My go-to site for this is: http://pudim.com.br

Pudim is portuguese for pudding. This website runs for as long as I can remember and there is only low-res photograph of a pudding.

same kind of website but easier to remember for me: http://neverssl.com

And http://nevertls.com works too, so it's really dead simple to remember.

Neat to see all the alternatives. I'm not sure what non-technical folks do when faced with this problem, so I picked a friendly domain name.

Ironically, if CoffeeShopWifi.com works successfully, the users won't see it.

I use http://motherfuckingwebsite.com, because I'm usually in a swearing mood if I need to use it. I've also always wondered what non-technical folks do.

They go up to the counter and complain that The WiFi isn't working.

Ha, good point.

It seems that HTTPS is available which made my browser (in HTTPS-only mode) connect to the HTTPS site. I suppose that if HTTPS was blocked it would allow me to fall back to HTTP but it gives a much less clear error than something like http://neverssl.com/ does.

this doesn't explain why you should connect to the site or would need to use it. That first paragraph could describe the scenario.

As I haven't been inside a coffee shop or any public wifi scenario in over a year I was trying to remember what the use case was for this....

From reading the comments, this is for use in scenarios where you connect to a guest wifi network, but aren't automatically taken to their authentication page to get access to the internet.

By trying to connect to a http:// website instead of https://, the redirect will work, allowing you to authenticate your device and access the internet.

Yeah, captive portals are annoying. I got so frustrated with trying to connect to Starbucks' WiFi that I ended up writing my own script [1] that would allow me to authenticate from my terminal. I even wrote about what happens behind the scenes when you connect. [2]

1: https://github.com/imwally/coffeeconnect

2: https://nil.wallyjones.com/what-happens-when-you-connect-to-...

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?

Basically, because the captive portal tries to redirect the browser to a page for authentication, but the browser won't let this through on a https connection for security reasons.

https://en.wikipedia.org/wiki/Captive_portal#Require_Web_Bro...

Wifi with captive portals work by redirecting all of your outgoing traffic to a specific host - send a packet to 12.34.56.78 and it gets natted to 10.0.0.1 (or wherever the captive portal is).

When you connect to wifi, many (most?) OSes and/or browsers issue requests to http servers run by apple/firefox/microsoft. If the response is a portal, a popup is shown to allow the user to login (typically logging in would authorise the IP and/or mac address in a database and allow traffic to pass).

However some (poorly implemented) hotspots have specific holes to allow these pages to load without the portal (whitelisting the domains), then when you try to visit http://othersite.com, you will be redirected. Other portals may timeout after X minutes or X MB of use and require reauthentication, which the OS/browser may not detect.

As more and more sites use https, while the connection can be stopped (by stopping traffic going to port 443), a correctly behaving browser should ignore any traffic coming from a redirected https connection, as it wouldn't have a valid certificate - it's the whole point.

Many sites also implement headers which tell a browser "you will always connect to me on http", and the browser will refuse to downgrade to http://othersite.com, even if port 443 (https) is blocked but port 80 is open.

By visiting neverssl.com or similar sites, you can in those situations trigger the captive portal login page.

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 is an HTTPS website, the browser asks for an HTTPS certificate from this fake google.com and the router is unable to deliver a "real" certificate—this then breaks the "login flow" since instead of seeing a login form you see a "danger, do not continue, bad certificate" page.

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.

Um, your browser would complain about a self-signed certificate even if there was no pinning. Otherwise SSL/TLS would be useless.

I ctrl-f'd and didn't see anyone mention that you can look at your wifi settings, and visit the router aka default gateway IP to connect to the portal directly.

So like if your settings say your gateway is 192.168.0.1, go to https://192.168.0.1

This will work in situations where even a site like coffeeshopwifi.com doesn't

I've noticed neverssl.com and others failing for me the past couple months. The browser caches them so the page is never redirected.

Sounds like someone needs to build neverssl-nevercached.com with a "Cache-Control: no-store" header

I just go to 192.168.1.1 and it works fine most of the time (I can't remember when it didn't work, but just in case...)

I used to use purple.com for this. Anyone who used it back in the golden age of the internet knows it was ideal for such purposes. It even had that squirrel game. Anyway after many many years of serving that masterpiece over plain http the guy sold the domain to some fucking matress company who insists on SSL.

I use http://neverssl.com :)

My personal website (the top level index) is effectively a brochure with nothing that could be used for authenticating (there's a very broken javascript crypto app on it but that's just a toy and is clearly marked as such.) I always just use that.

http://zombo.com

Basically, http://clients1.google.com/generate_204 with a more memorizable URL

I use http://asdf.com for this. The main advantage being its so easy to type

I thought most devices had solved this with their own captive portal detection logic and websites now. Is that not the case?

Similarly http://http.rip/ is short and memorable

I like to use http://http.rip/ for this!

OT: But the website's source has a great way to stop (I guess most) web scrapers from scraping email addresses.

I wish captive WiFi sign in pages would just go away. They hinder usability while providing no value to anyone.

I own and maintain dingleberrypie.com and maintain it as a non-HTTPS site for exactly this reason.

I use att.com if the OS doesn't show the portal automatically, it's nice and short.

I use t.co (owned by twitter). Its major benefit is extremely short to type and no https.

> Coffee Shop Wifi always connects with HTTP instead of secure HTTPS. This allows guest wifi networks to show you their internet login page.

I always go to http://paulgraham.com when I need to connect to guest WiFi for the exact same reason..

Don't most OSes include a mechanism to visit a non-SSL site automatically?

fails to work often enough

Can't you always just go to 10.0.0.1?

I always use lolwut.com for this

This is one of those ideas, so simple, so necessary, so brilliant, that I'm jealous I didn't come up with it.

Great work!

Neverssl.com is nice too

I go to 1.1.1.1

Reply on news.ycombinator.com