I really wish there was a standard way of handling captive wifi portals, macOS and GNOME try to detect these portals and show them but sometimes it is unreliable.
It'd be really nice if there was a reserved DNS entry (like captive.portal or something) that operating systems could try to resolve and if it points to anything other than an expected value (loopback address, maybe?) it will bring up a window to sign into the network instead of relying on these nasty hacks that leave users confused when they can't visit a site over HTTPS because they aren't authenticated / paid / whatever.
So far I have had quite a few issues with HSTS, not allowing me to access web sites, or authenticate with WiFi networks, to the point that on Android 4.3 I use the outdated system browser for authentication and only afterwards switch to Chrome.
There is; both Router Advertisements and DHCP include options for captive portals[1]. In the case of DHCP for example, the DHCP server can send the URI of the portal, which the OS can display to the user. The mechanism in [1] is what OS X uses, I believe.
It's so annoying that I even wrote a script so I could connect to Starbucks WiFi without having to use a browser. This was back when I was on Linux using a tiling window manager but I still use it on macOS because it's useful.
Hey, thanks mate. With the various meetups I go and corporate networks I'm using, it's always a pain to lose all my saved chrome tabs to portal redirects because I forgot to open Firefox to get through the portal first. I might be able to leverage this to help.
I'm glad that there isn't a standard. Implementing a captive portal should be a painful experience that ultimately results in giving up and not using one.
If I regularly used that as a known-good site that should be up with no SSL, I'd trust that an apple-maintained site (backed by akamai) would be up before "example.com".
I'm sure there are plenty of others, but someone might remember that URL over another so I thought it would be helpful.
example.com is maintained by IANA. It's an official example address for documentation purposes. So on one hand, it will survive even if Apple disappears, on the other, they're likely not expecting any significant traffic.
Using the site for captive portal access does not actually generate any traffic for the site, because the middlebox intercepts and rewrites the request. Traffic only occurs if there is no captive portal. Hence the easily parsed "Success" body of the Apple site.
Phones confirm whether you passed the captive portal by requesting the usual check url again. That means they'll still get one request after a successful login.
It's reserved for the purpose of documentation/illustrations (especially RFCs themselves) without fear of changes/invalid domains/directing mass traffic. It's also useful for establishing an idiom for those RFC examples.
Any site that doesn't redirect to the SSL version (if applicable) will work. The benefit of using something like captive.apple.com is that it's specifically designed to NOT use SSL in order to trigger redirects and such, whereas something like example.com just so happens to not redirect to their SSL version, so it's (essentially) guaranteed to work vs example.com who could decide in the future to redirect to their SSL version if they want
My iPhone constantly misses captive portals and I have to hunt for a non-ssl website. I can't say if it's 5% or 30% of networks, but enough to be frustrating. Does anyone know if it is common for apple.com to be whitelisted for iMessage or something?
The captive portal browser (pop-up on macOS, slide-over on iOS) doesn't support full JavaScript or cookies (or previously didn't, maybe that has changed), so some captive portals specifically allow the captive portal test domains through.
I've never seen a setting for it. It's just a modal dialog with a webview. Like iOS, you have "Cancel" as an option until it connects and changes to "Done."
Except some portals actively try to avoid intercepting any of Apple's methods for determining whether you're on one. You're much better off with an off the beaten path solution.
Not sure about Apple, but isn't this automatically handled by Android these days? Every time it connects to a network it pings http://google.com/generate_204 and if the response code isn't 204 then it should prompt you to open the browser to the redirected URL.
Apple has been using http://captive.apple.com/ for years. Their UI for it has gotten a lot better, too. Previous versions you'd get a popup, but you could dismiss it and it would disconnect from the network (which sucks if you're /trying/ to connect to a network without Internet). Now it has a few more options and ways to get back to the popup--but I still have issues with certain networks.
Well, this was my solution before this shorter way came along. A force of habit, really, since I noticed that it was Android's internal method of detecting captive portals. There's really no reason to use this over neverssl.com, other than the gstatic.com page returning an empty response (or redirecting you if you're actually behind a captive portal). Somewhat useful if you don't want to leave the new tab page.
It's sad, because these are the kinds of things that confuse the hell out of "common folk" and explaining requires explaining HTTPS, HSTS, how captive WiFi portals work, and then ultimately, why there isn't a better solution... which maybe doesn't have a great answer.
I feel like this "workaround" site is designed to draw attention to the problem at hand more than it is meant to be useful for the task at hand?
I still think having people connect to something handed out by dhcp would be really great, that's what dhcp is for in the first place. If that's too complicated you could always try connecting to the gateway.
So is there a matching method to neatly introduce MITM in the connection? Our portal would let you log on but you'll still fail to connect to anything as we have to inspect it.
> So is there a matching method to neatly introduce MITM in the connection?
No, for fairly obvious reasons. If you MITM traffic, clients will correctly flag security errors. No method exists or ever should exist for a network to cause clients to not flag such security errors. Any such method would defeat one of the primary purposes of TLS: to protect against hostile networks.
> Our portal would let you log on but you'll still fail to connect to anything as we have to inspect it.
For what purpose? I have not seen any legal jurisdiction sufficiently draconian to impose such a requirement. (I've seen a few terrible ones that might require logging IP addresses.)
I know MITM should never be silent of course but some kind of interaction flow would be good. When you try to add a school account to your android it won't let you if you don't install the MDM client. A similar thing for the network would be great (of course, the MDM will install the cert).
I'd love if I could also pin our MITM cert to only be valid when the client is on our IP address' which if using ipv6 could work very nicely.
put the payment url on a sign, just enforce an ip whitelist until customer has paid. Or in extreme sign-less situations put it in the ssid e.g. "pay at portalpage.com"
> put the payment url on a sign, just enforce an ip whitelist until customer has paid. Or in extreme sign-less situations put it in the ssid e.g. "pay at portalpage.com"
This is a captive portal. But worse, because even HTTP sites don't send you to the portal.
* no MITM attack
* no TLS cert errors
* no "do I need to hard-refresh? what's the key for that?"
* no question if network access is working or not
* one reliable clear action to get access
See the various comments about work-arounds for work-arounds. Random plain-http intercept-check sites because some captive portals try to make iOS not pop up the mini sandboxed captive portal browser. The endless confusion.
This stuff would be a lot simpler if people weren't always trying to make it needlessly "easy" and fucking it up even more every time.
WPA/WPA2 Enterprise supports a multi user environment. You can require a unique login per user and thus associate payment with that. It also alleviates the problem with mac address whitelisting.
> Do you think hotels and restaurants can deliver reliable internet without charging for it?
Many do. I've never seen a restaurant charging for Wifi, and I've seen plenty offering it for free. Quality varies, some are good, some suck. Hotels are all over them map, but I just stayed at the hotel that advertises free high quality Wifi (and it indeed was fine) as one of the amenities.
US-centric, of course, in some places I guess it many be too expensive for restaurants to do this.
It shouldn't be too expensive for a restaurant to do.
Although a restaurant can get by without wifi, most modern restaurants have it for managing OpenTable, monitoring yelp reviews, ordering supplies online, etc.
I guess the signal might get a bit worse the farther away you get from the wifi router, but in general, providing wifi to customers shouldn't cost any additional money.
I think the real cost isn't that they use wifi, but that they actually sit around longer but purchase less in their time spent at the establishment. It's really important for restaurants to turn tables over quickly.
> Do you think hotels and restaurants can deliver reliable [[tap water]] without charging for it?
> Is it reasonable to assume that companies that don't charge for [[tap water]] can afford the staff to make sure that users don't abuse it?
Sorry to post the snarky response, but with internet access, as with all shared goods like access to water or noise in a semi-shared space such as a hotel, yes, I do expect they can handle it and not have it be a big deal.
I wonder why this seems so intractable in some countries. In others, such as Indonesia or Vietnam or Taiwan, WiFi really is free in most establishments and nobody seems to have a problem with customers abusing it. Even a $10 hotel has WiFi. Versus say London where a $300 hotel charges $25 for WiFi. In many places nobody would ever expect to pay one cent for WiFi in a place where they are already a paying customer unless it's an Internet cafe.
"Versus say London where a $300 hotel charges $25 for WiFi."
It's almost an inverse relationship, in my experience. The economy to medium-priced "business travel" hotels (the sort found near most U.S. airports) usually have free wifi, while the fancy "luxury" hotels often charge for it.
> Do you think hotels and restaurants can deliver reliable internet without charging for it?
Absolutely. 100% of the hotels that I've stayed at in the last five years have had free wifi. Almost half of those have still had captive portals.
Hell, my gym provides free wifi. The captive portal is literally just a button that says "Continue to the Internet" and redirects you to their Facebook page (not even a terms of use).
Every Starbucks I've been in recently has free wifi. Every library I've visited has had captive portal-free wifi.
I don't understand what sort of "scaling" you're referring to.
Most restaurants in Germany do. You'd have to explicitly and sometimes adamantly request "tap water" to get access to free water, otherwise you'll be served and charged for fancy "mineral water".
Honestly? It's 2017. Just throttle bandwidth and give your internet away for free.
There are some obvious cases in which this is unacceptable, but they are few and far between. The overwhelming majority of captive portals I see are just trying to get your contact info... so now you have two reasons why they should disappear.
Ah, first world problems. Where I am, data connections are out of reach for the vast majority of the population (yet somehow, they all seem to have smartphones - go figger).
Everyone goes to the mall, not to shop, it would seem, but to use the free wifi and bask in the comfort of free aircon.
Captive portals are here to stay in places around the world, and like it or not, they are a widely used solution that is not going away any time soon. I for one applaud the author of this website's attempts to shine light on the problem of authenticating to this network type.
$20 is one month worth of broadband in some countries. Anybody can do what he wants with his money, but $2 would be a more appropriate price tag for a few hours of Internet. If you're working, $20 could be OK though because you're gaining more.
It also depends on where you are. Getting high-speed, low-latency internet to a shopping centre in the middle of a metropolitan area is probably a bit easier and cheaper than getting it to a plane flying 40000 feet above the Atlantic. And while I probably wouldn't pay $20 for eight hours of internet on a plane (unless I really needed it), I don't find the price tag entirely unjustified.
Most captive portals I run across are trying to verify that you are in fact a paying customer. Typically by making you enter your hotel room number and name or something.
Normally you would think it would just be easier to set a wifi password and skip the captive portal nonsense, but so many vendors harbor the fantasy that other people will pay for the wifi so they have to leave it open and put a "buy 24 hours of internet for only $30!" link in there.
I hate captive portals. They are such a nuisance, especially when you have your machine configured to always connect via VPN.
Almost none of the captive portals I run into want payment of any kind; they almost always just have a click-through for "don't abuse this network" or similar terms.
If you really want payment, then post a URL wherever you post a sign about the SSID, and/or make the SSID "Go To example.com after connecting".
My real plan with NeverSSL.com is to use the access logs to publish an up-to-date database of broken networks and what the rough popularity of each broken network is.
I'm hopeful that these kinds of public analytics could lead to solutions, or at least who to start talking to.
Since this involves information capture, you should let people know on the page. Although admittedly the naive user, for whom this is intended, may be confused by that.
The problem isn't even so much with captive portals, but only with those actively trying to circumvent captive portal detection provided e.g. by iOS (as pointed out above). "Regular" captive portals will be captured by iOS and you can log-in via the mini browser before any requests to Facebook etc. go through - problem solved (albeit in a very hacky way).
The problem only (re-)materialises when some smartass developers actively try (and succeed) to break portal detection (my guess is that they do it because iOS will close the portal once the Internet connection works, so all the nice ads they want to display just disappear).
IIRC the big problem is that Apple severely restricts the captive portal displaying minibrowser, so the tracking cookies they want to inject don't work.
Windows does the same thing, at least in 10. I get a notification that further action is required and clicking it opens a no-SSL Microsoft URL that Will redirect.
Do you travel? I often have problems and am running out of non-https sites to test against. Best I can figure is that they're whitelisting certain domains so the captive portal detection isn't triggered. I think this is so certain things like iMessage or email work (hence, whitelisting apple.com), but blocking out the rest of the web.
I don't travel often (Christmas and maybe once or twice a year outside of that), but it's when I encounter this. It's very frustrating because I'll be walking, pass a store I've previously connected to Wifi, and suddenly lose Internet, then hunt for a website to get the portal to pop up.
I'm annoyed that captive portals have been commonly using DNS hacking since 802.11b and I'm surprised a better solution hasn't been standardized. I have no idea where in the stack it should go (DHCP, wireless standards, or whatever) but DNS hacking drives me nuts.
Really? My point was, I have no specific idea why, but I /constantly/ have problems. My solution is to go to a non-https website in Safari and use the clickthrough. It seems to be on certain networks (not just a % of the time on all networks).
The experience has gotten a lot better. I see Apple's pop up covering a lot more corner cases, but after years I see have problems almost every time I travel.
I just make up fake sites to see if I'm stuck behind a captive portal because too many times I've accidentally loaded a cached version instead and not realized that I'm being blocked. fjiodfakliew.com or something.
The most sensible option would be a DHCP extension that indicates you are behind a portal and gives the IP to load, but this requires updates to every DHCP server and client, so it would take many years before it works reliably. Also, it fails for IPv6, but a modification to the Router Advertisement message could maybe do the same thing. It's a little scarier in this regard because it would be even easier to abuse.
The question that I always ask family is, "Can you get to www.purple.com if you're having trouble?" It does what it says, is easy to understand, and is obvious if it's not functional.
My family always rhetorically asks "Why is this so hard?" or "Why does this never seem to work?" - which I never answer, because they are asking rhetorically, but also because there are a lot of deep technical issues you need to know about before you understand the common implementation and then I'm not sure I can explain why we dont have a better implementation.
You could set one up with a regular router but you need something you can customize, be it the router itself, a raspberry pi, or a desktop PC acting as a server. And yeah, you've got it, the router needs to allow DNS to be customized so clients get pointed to a system that (intentionally) MiTMs requests and returns a http 302 redirect to go to the portal page.
Usually they let DNS resolve normally (because intercepting at this level will break the website even after you've satisfied the captive portal) and intercept any HTTP connections, responding with a temporary redirect to a controlled domain. Doing this with a mere DNS server will only work if you don't visit the website you initially tried to access for a while after you connect. It's also super easy to bypass; just pick a public DNS server instead of the one the network tries to assign to you.
To do this properly either your router or switch/AP need to be configured to do the necessary rewriting as well as maintain a list of authenticated clients. Your best bet to do this with something in the consumer(ish) price range without a custom firmware like OpenWRT is something like a Uni-Fi access point which can handle the captive portal interception itself.
Can't I use a regular consumer router but hook up a computer on the LAN to do something? Intercept DNS? Intercept HTTP requests like you said? But the problem is what if the user makes https requests?
All I want to do is make a system which "takes attendance" via the phones automatically trying to join the local network, and I use the session is to look up the user. People would have accounts where they log in once via the captive portal and then the attendance would happen automatically.
Basically I want to make a captive portal with regular routers so I can sell the solution to regular venues.
Think about it this way: if you could do it with a random computer on the network without special cooperation from the router, what would stop someone from connecting to your network with this software you propose and doing the same? As I explained, telling your router to instruct your clients to use a particular DNS server isn't nearly enough.
The closest you could get would be to use another computer with 2 network cards as the actual router (running something like PFSense), and set up a consumer WiFi router as an access point instead of a router. This would only work as long as you don't mind the clients being able to connect to the rest of you local network; if that's an issue you really need something like a captive portal aware AP/switch or a VLAN.
However this solution doesn't make much sense in the end, as it would be much cheaper to buy one of the cheaper commercial-grade APs (UniFi's are around $80) and use your "regular router" with WiFi disabled than it is to buy a computer for that purpose. Those APs are also better quality than any consumer router you could find, and scale up much better for larger venues.
Also TBH if you're not aware of how captive portals work and why it can't be done by a random computer on your network, this is probably not a good business venture for you. This isn't an unsolved (or expensive to solve) problem to begin with.
I know it isn't an unsolved problem. That's my point. I have the software to run on a local area network and now I just want to explore the right ways to actually set up our own captive portals on those networks.
Consider a building or cruise ship with an existing network. It's a much harder sell to say "replace all your routers" or "flush all your routers and install our firmware" than to say "use your existing router and just set up our DNS server on a computer".
What networks have you seen that have more than one router and use consumer routers? Even medium sized networks often have only one router and multiple switches. You can get a router that can handle a captive portal and push a million packets per second for around $100. How little are you going to charge for your solution that it's going to be cheaper than that?
Yep. Most default browser homepages use SSL, as do many popular second locations like Facebook. It can get a bit annoying to remember who won't serve you SSL when you're waiting to get an approval page injected into your browsing, so this site promises to do it.
It's especially relevant now that Chrome is threatening a big unsecure site warning for HTTP pages, so many sites which don't strictly need security are going to switch.
This is handy. I was at an airport and was helping numerous people with android devices get through the wifi portals, and dealing with the same frustrating failure of the captive-portal redirect. Android is supposed to detect that there's a redirect and give you a notification that takes you to the login page, but it's very inconsistent.
I usually use Xkcd for that purpose, one of the few lightweight non-ssl sites I can think of offhand.
Only problem with neverssl is that it's a big jargon-laden for laymen, I mean the name.
I bought unencryptedwebsite.com last week after running into the same problem without knowing that neverssl.com exists. I still have to set it up, though. Too bad I'm lazy. :/
There is no (working!) https version of the domain. I own/maintain neverssl.com and I'll be doing my best to make sure that it can never poison the intended experience. I use it myself.
Basically, it's designed to be easy to remember, and over time I'll deploy whatever "Nope, really use HTTP" workarounds are available as TLS-by-default, and maybe even DANE, gain traction.
The difference between neverssl.com and others is just that "guarantee" and the slightly tongue-in-cheek text that tries to make it clear to users what's going on.
Actually right now I'm on a plane, between Newark and Seattle, and just typed it in to log in ... only to see it featured on HackerNews. Mind Blown. I'm coming back from 7 days spent with other implementors of TLS, and it's something I stay up to date on. That's it.
It's pretty weird that example.com does not use https:// , I expect it will in the near-future. Part of its job is to set a good ... example.
Leaving this feedback here because there's no contact info on the page: for the purpose of accessing captive portals, it would be a good idea to disable page caching. Since this was posted I've had to use it twice and the second time I had to hard refresh to see the portal.
211 comments
[ 2.9 ms ] story [ 261 ms ] threadIt'd be really nice if there was a reserved DNS entry (like captive.portal or something) that operating systems could try to resolve and if it points to anything other than an expected value (loopback address, maybe?) it will bring up a window to sign into the network instead of relying on these nasty hacks that leave users confused when they can't visit a site over HTTPS because they aren't authenticated / paid / whatever.
[1]: https://tools.ietf.org/html/rfc7710
https://github.com/imwally/starbucksconnect
I'm sure there are plenty of others, but someone might remember that URL over another so I thought it would be helpful.
[1] https://www.ietf.org/rfc/rfc2606.txt
[2] https://en.wikipedia.org/wiki/Example.com
There's actually a huge list of domains that macOS/iOS try: http://stackoverflow.com/questions/18891706/ios7-and-captive...
I have never seen a captive portal interceptor on MacOS (much to my disappointment), only iOS. Is there some setting I previously screwed up?
Here's a screen shot I found: https://www.wireless.bris.ac.uk/gfx/eduroam-osx/captive_port...
Because of this thread I simulated it on my network and couldn't cause it to show up.
according to https://github.com/android/platform_frameworks_base/blob/5b2...
I feel like this "workaround" site is designed to draw attention to the problem at hand more than it is meant to be useful for the task at hand?
No, for fairly obvious reasons. If you MITM traffic, clients will correctly flag security errors. No method exists or ever should exist for a network to cause clients to not flag such security errors. Any such method would defeat one of the primary purposes of TLS: to protect against hostile networks.
> Our portal would let you log on but you'll still fail to connect to anything as we have to inspect it.
For what purpose? I have not seen any legal jurisdiction sufficiently draconian to impose such a requirement. (I've seen a few terrible ones that might require logging IP addresses.)
I know MITM should never be silent of course but some kind of interaction flow would be good. When you try to add a school account to your android it won't let you if you don't install the MDM client. A similar thing for the network would be great (of course, the MDM will install the cert).
I'd love if I could also pin our MITM cert to only be valid when the client is on our IP address' which if using ipv6 could work very nicely.
There is a better solution: No captive portals.
Like it or not, a lot of places do that.
This is a captive portal. But worse, because even HTTP sites don't send you to the portal.
This stuff would be a lot simpler if people weren't always trying to make it needlessly "easy" and fucking it up even more every time.
I think we should move towards considering Internet access as a general service that people make available for their guests/customers.
Do you think hotels and restaurants can deliver reliable internet without charging for it?
Is it reasonable to assume that companies that don't charge for wifi can afford the staff to make sure that users don't abuse it?
I am considering your proposal & I don't see it working at all.
Many do. I've never seen a restaurant charging for Wifi, and I've seen plenty offering it for free. Quality varies, some are good, some suck. Hotels are all over them map, but I just stayed at the hotel that advertises free high quality Wifi (and it indeed was fine) as one of the amenities.
US-centric, of course, in some places I guess it many be too expensive for restaurants to do this.
Although a restaurant can get by without wifi, most modern restaurants have it for managing OpenTable, monitoring yelp reviews, ordering supplies online, etc.
I guess the signal might get a bit worse the farther away you get from the wifi router, but in general, providing wifi to customers shouldn't cost any additional money.
Heck, most McDonalds restaurants have free wifi these days, and that's about as cheap as it comes.
> Is it reasonable to assume that companies that don't charge for [[tap water]] can afford the staff to make sure that users don't abuse it?
Sorry to post the snarky response, but with internet access, as with all shared goods like access to water or noise in a semi-shared space such as a hotel, yes, I do expect they can handle it and not have it be a big deal.
Internet WIFI should be treated as a condiment. A business that can't afford condiments probably shouldn't be in business.
Yes. Because most already do.
It's almost an inverse relationship, in my experience. The economy to medium-priced "business travel" hotels (the sort found near most U.S. airports) usually have free wifi, while the fancy "luxury" hotels often charge for it.
I simply choose better hotels.
Absolutely. 100% of the hotels that I've stayed at in the last five years have had free wifi. Almost half of those have still had captive portals.
Hell, my gym provides free wifi. The captive portal is literally just a button that says "Continue to the Internet" and redirects you to their Facebook page (not even a terms of use).
Every Starbucks I've been in recently has free wifi. Every library I've visited has had captive portal-free wifi.
I don't understand what sort of "scaling" you're referring to.
There are some obvious cases in which this is unacceptable, but they are few and far between. The overwhelming majority of captive portals I see are just trying to get your contact info... so now you have two reasons why they should disappear.
Everyone goes to the mall, not to shop, it would seem, but to use the free wifi and bask in the comfort of free aircon.
Captive portals are here to stay in places around the world, and like it or not, they are a widely used solution that is not going away any time soon. I for one applaud the author of this website's attempts to shine light on the problem of authenticating to this network type.
> but $2 would be a more appropriate price tag for a few hours of Internet
Correct. That's (one of the reasons) why Starbucks coffee is pricier.
IIRC in some countries they're required (by law) to do so, because, y'know, terrorists.
Normally you would think it would just be easier to set a wifi password and skip the captive portal nonsense, but so many vendors harbor the fantasy that other people will pay for the wifi so they have to leave it open and put a "buy 24 hours of internet for only $30!" link in there.
I hate captive portals. They are such a nuisance, especially when you have your machine configured to always connect via VPN.
If you really want payment, then post a URL wherever you post a sign about the SSID, and/or make the SSID "Go To example.com after connecting".
I'm hopeful that these kinds of public analytics could lead to solutions, or at least who to start talking to.
Good idea by the way!
The problem isn't even so much with captive portals, but only with those actively trying to circumvent captive portal detection provided e.g. by iOS (as pointed out above). "Regular" captive portals will be captured by iOS and you can log-in via the mini browser before any requests to Facebook etc. go through - problem solved (albeit in a very hacky way).
The problem only (re-)materialises when some smartass developers actively try (and succeed) to break portal detection (my guess is that they do it because iOS will close the portal once the Internet connection works, so all the nice ads they want to display just disappear).
I don't travel often (Christmas and maybe once or twice a year outside of that), but it's when I encounter this. It's very frustrating because I'll be walking, pass a store I've previously connected to Wifi, and suddenly lose Internet, then hunt for a website to get the portal to pop up.
I'm annoyed that captive portals have been commonly using DNS hacking since 802.11b and I'm surprised a better solution hasn't been standardized. I have no idea where in the stack it should go (DHCP, wireless standards, or whatever) but DNS hacking drives me nuts.
The experience has gotten a lot better. I see Apple's pop up covering a lot more corner cases, but after years I see have problems almost every time I travel.
The most sensible option would be a DHCP extension that indicates you are behind a portal and gives the IP to load, but this requires updates to every DHCP server and client, so it would take many years before it works reliably. Also, it fails for IPv6, but a modification to the Router Advertisement message could maybe do the same thing. It's a little scarier in this regard because it would be even easier to abuse.
Can I set one up on a home network with a regular router without WifiDog or some other OpenWRT firmware?
Maybe somehow use one of the computers on the network to run a DNS server that all requests go through??
To do this properly either your router or switch/AP need to be configured to do the necessary rewriting as well as maintain a list of authenticated clients. Your best bet to do this with something in the consumer(ish) price range without a custom firmware like OpenWRT is something like a Uni-Fi access point which can handle the captive portal interception itself.
All I want to do is make a system which "takes attendance" via the phones automatically trying to join the local network, and I use the session is to look up the user. People would have accounts where they log in once via the captive portal and then the attendance would happen automatically.
Basically I want to make a captive portal with regular routers so I can sell the solution to regular venues.
How do these guys do it:
https://www.fusionwifi.com/
There are a lot of social wifi solutions now
If you can MitM connections on your network just by connecting a client to it, with no particular participation from the router, your network sucks.
Your linked site notes that they provide the router hardware.
The closest you could get would be to use another computer with 2 network cards as the actual router (running something like PFSense), and set up a consumer WiFi router as an access point instead of a router. This would only work as long as you don't mind the clients being able to connect to the rest of you local network; if that's an issue you really need something like a captive portal aware AP/switch or a VLAN.
However this solution doesn't make much sense in the end, as it would be much cheaper to buy one of the cheaper commercial-grade APs (UniFi's are around $80) and use your "regular router" with WiFi disabled than it is to buy a computer for that purpose. Those APs are also better quality than any consumer router you could find, and scale up much better for larger venues.
Also TBH if you're not aware of how captive portals work and why it can't be done by a random computer on your network, this is probably not a good business venture for you. This isn't an unsolved (or expensive to solve) problem to begin with.
Consider a building or cruise ship with an existing network. It's a much harder sell to say "replace all your routers" or "flush all your routers and install our firmware" than to say "use your existing router and just set up our DNS server on a computer".
1. http://xkcd.com
I'd love to be in the meeting where they discuss adding security features lowers their traffic volumes...
It's especially relevant now that Chrome is threatening a big unsecure site warning for HTTP pages, so many sites which don't strictly need security are going to switch.
I usually use Xkcd for that purpose, one of the few lightweight non-ssl sites I can think of offhand.
Only problem with neverssl is that it's a big jargon-laden for laymen, I mean the name.
Basically, it's designed to be easy to remember, and over time I'll deploy whatever "Nope, really use HTTP" workarounds are available as TLS-by-default, and maybe even DANE, gain traction.
The difference between neverssl.com and others is just that "guarantee" and the slightly tongue-in-cheek text that tries to make it clear to users what's going on.
Actually right now I'm on a plane, between Newark and Seattle, and just typed it in to log in ... only to see it featured on HackerNews. Mind Blown. I'm coming back from 7 days spent with other implementors of TLS, and it's something I stay up to date on. That's it.
It's pretty weird that example.com does not use https:// , I expect it will in the near-future. Part of its job is to set a good ... example.
AHA! That's it. Now it makes sense.
Easier to type and they never plan to add HSTS because of that reason.
Update: I've added Cache-Control and Expire HTTP headers to the HTTP responses for neverssl.com