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).
Also worth noting that example.net, while not listed on the IANA page, is also reserved.
https://datatracker.ietf.org/doc/html/rfc6761#section-6.5
> The domains "example.", "example.com.", "example.net.", "example.org." [...]
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)
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.
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.
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.
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.
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.
Does any such standard feature already exist?
https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Pro...
It says:
Perdu sur l'Internet ?
Pas de panique, on va vous aider
* <----- vous êtes ici
Lost on the Internet?
Don't panic, we are going to help you
* <----- you are here
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.
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.
Ironically, if CoffeeShopWifi.com works successfully, the users won't see it.
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....
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.
1: https://github.com/imwally/coffeeconnect
2: https://nil.wallyjones.com/what-happens-when-you-connect-to-...
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.
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.
https://en.wikipedia.org/wiki/Captive_portal#Require_Web_Bro...
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.
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 always go to http://paulgraham.com when I need to connect to guest WiFi for the exact same reason..
Great work!