[HN Gopher] CoffeeShopWifi.com - An HTTP website for connecting ...
___________________________________________________________________
CoffeeShopWifi.com - An HTTP website for connecting to guest WiFi
Author : jastr
Score : 116 points
Date : 2021-07-08 13:43 UTC (9 hours ago)
(HTM) web link (coffeeshopwifi.com)
(TXT) w3m dump (coffeeshopwifi.com)
| darwinwhy wrote:
| http://zombo.com
| rodonn wrote:
| I use t.co (owned by twitter). Its major benefit is extremely
| short to type and no https.
| franze wrote:
| Similar to http://neverssl.com/ I guess?
| ahomaily wrote:
| awfully similar :)
| BoorishBears wrote:
| 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.
| irq-1 wrote:
| 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.
| mike_d wrote:
| I believe http://wifi.yt (you there?) predates most of these.
| notwedtm wrote:
| Ah, the old MySpace argument.
| hkolk wrote:
| same kind of website but easier to remember for me:
| http://neverssl.com
| staticassertion wrote:
| And http://nevertls.com works too, so it's really dead simple
| to remember.
| sbr464 wrote:
| http://www.neverssl.com
| ykat7 wrote:
| 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
| sigjuice wrote:
| 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.
| notwedtm wrote:
| 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.
| sigjuice wrote:
| 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
| srhngpr wrote:
| Agreed - I always use example.com as well.
|
| Also worth noting that example.net, while not listed on the
| IANA page, is also reserved.
| derimagia wrote:
| 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." [...]_
| colejohnson66 wrote:
| iOS (and macOS?) use http://captive.apple.com/
| forty wrote:
| That means apple.com cannot be HSTS preloaded, which is too
| bad for security.
| mwambua wrote:
| I've used this on Linux as well.
| pftburger wrote:
| Yea I use this manually some times as well.
|
| Great for low bandwidth tests Just displays clean "success"
| hartator wrote:
| Clean "Success" sssSsss
| imwillofficial wrote:
| I read this in the voice of Cobra Commander
| elcritch wrote:
| I like neverssl.com, it's a nice basic text page.
| moftz wrote:
| Mozilla also has one that Firefox will use when detecting
| captive portals:
| http://detectportal.firefox.com/success.txt
| 0xbadcafebee wrote:
| 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)
| groby_b wrote:
| 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.
| droopyEyelids wrote:
| 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
| imwillofficial wrote:
| 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!
| c0nsumer wrote:
| I own and maintain dingleberrypie.com and maintain it as a non-
| HTTPS site for exactly this reason.
| tyingq wrote:
| I thought most devices had solved this with their own captive
| portal detection logic and websites now. Is that not the case?
| jraph wrote:
| I use http://perdu.com/
|
| It says: Perdu sur l'Internet ? Pas de
| panique, on va vous aider * <----- vous etes
| 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 for decades (amazingly), 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 useful on spotty / weak
| connections).
|
| Hard to beat.
| [deleted]
| gmontanola wrote:
| 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.
| mahathu wrote:
| I use att.com if the OS doesn't show the portal automatically,
| it's nice and short.
| vincentmarle wrote:
| > 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..
| wyldfire wrote:
| 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?
| yabones wrote:
| 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...
| AnIdiotOnTheNet wrote:
| 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.
| gsich wrote:
| There are some RFC7710 and 8910 come to mind.
| lxe wrote:
| I go to 1.1.1.1
| denysvitali wrote:
| Basically, http://clients1.google.com/generate_204 with a more
| memorizable URL
| robbiemitchell wrote:
| 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?
| topher515 wrote:
| 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.
| moftz wrote:
| 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.
| boring_twenties wrote:
| Um, your browser would complain about a self-signed
| certificate even if there was no pinning. Otherwise SSL/TLS
| would be useless.
| gattilorenz wrote:
| 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...
| iso1210 wrote:
| 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.
| jonny_eh wrote:
| Don't most OSes include a mechanism to visit a non-SSL site
| automatically?
| pantalaimon wrote:
| fails to work often enough
| zacharycohn wrote:
| I always use lolwut.com for this
| jedberg wrote:
| 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.
| cjtrowbridge wrote:
| Neverssl.com is nice too
| jpetrucc wrote:
| I like to use http://http.rip/ for this!
| Y_Y wrote:
| 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.
| jaflo wrote:
| Similarly http://http.rip/ is short and memorable
| tarkin2 wrote:
| OT: But the website's source has a great way to stop (I guess
| most) web scrapers from scraping email addresses.
| jacobwil wrote:
| 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.
| Lt_Riza_Hawkeye wrote:
| 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
| stefan_ wrote:
| Getting "you had one job" vibes here.
| elgaard wrote:
| That is why I use x.com also has a very shall payload
| jastr wrote:
| 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.
| notwedtm wrote:
| > 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.
| bberenberg wrote:
| httpforever.com is the one I use. https connection gets
| redirected to http to ensure that it gets captured.
| CGamesPlay wrote:
| 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.
| ryan29 wrote:
| 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.
| ChrisArchitect wrote:
| 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....
| ameetgaitonde wrote:
| 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.
| firefoxd wrote:
| I've noticed neverssl.com and others failing for me the past
| couple months. The browser caches them so the page is never
| redirected.
| imwally wrote:
| 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-...
| larskarbo wrote:
| I use http://asdf.com for this. The main advantage being its so
| easy to type
| arthurcolle wrote:
| Can't you always just go to 10.0.0.1?
| kevincox wrote:
| 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.
| FanaHOVA wrote:
| 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...)
| ipv6ipv4 wrote:
| I wish captive WiFi sign in pages would just go away. They hinder
| usability while providing no value to anyone.
| swiley wrote:
| 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.
| jastr wrote:
| 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.
| Kluny wrote:
| 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.
___________________________________________________________________
(page generated 2021-07-08 23:01 UTC)