> HTTPS is explicitly designed to prevent a Monster-in-the-Middle (MiTM)
Monsters don't exist. If people are really committed to erase anything that has the word "man" in it, at least they should try to be less lazy and use a term for people outside kindergarten.
Ugg - who cares! Let the author use whatever language they are comfortable with, especially if they're trying to avoid offense. The meaning of the phrase is clear to everyone so what does it matter if they've used a different term.
Man was always intended as being gender neutral anyway:
>The term man (from Proto-Germanic *mann- "person") and words derived from it can designate any or even all of the human race regardless of their sex or age. In traditional usage, man (without an article) itself refers to the species or to humanity (mankind) as a whole.
True - but there's no reason why language shouldn't continue to evolve with society. There are many instances where common words or phrases have changed over time in line with changing societal conditions. "It's [supposed to mean | always meant] this" just isn't a great argument for such mutable systems as languages. Also it seems like such a tiny personal cost to tweak one's use of language where it may make a non-zero impact on some of our biggest social challenges.
There are other costs, like fragmentation: not everybody agrees that "monster" is a good replacement, and there are many places where it definitely isn't a good replacement. Then there's changes to documentation, wikis, and other written documents. Not to mention time spent discussing alternatives and spreading the word.
On a personal level, it may be a few tiny tweaks but also very tiny personal impact. On a global scale, it could be a larger impact but also takes a lot more effort (combined effort of millions of tiny tweaks). Whether that effort is worth the payoff is debatable, especially considering what other initiatives that effort could be directed to.
This is a good point :-) I suppose if we gradually evolve language over time then we amortise and reduce any cost. I don't think we necessarily need to go around rewriting any books for most issues - but if this blog author (and others) tweak their language, maybe the next book to be written on the issue will make a more meaningful step forward, without any refactor cost. In any case there seems to be be no argument here that a given author shouldn't choose to tweak their words as they see fit where meaning is still clear - something that the parent commenter was implying as an issue.
Is your contention here that there's somehow a human male with two Ethernet ports that is manipulating HTTPS traffic and I'm just too "lazy" to admit that?
You could certainly argue that "M" standing for "man" in this acronym is the most commonly accepted interpretation. There do appear to be a few others, though. "Monster" is mentioned second to "man", here: https://en.wikipedia.org/wiki/Man-in-the-middle_attack
Person is lazier - it doesn't even maintain the acronym. Perhaps if you'd suggested Malefactor in the Middle it would have been a more convincing argument? In general I don't consider 'monster' to be childish - it's often used to refer to sexual preditors, for example. What we're seeing in this line of discussion is that language is mutable and subjective - and for that reason the author's use of words is a justified as any other.
I absolutely hate this nonsense. They cause countess headaches just to make people click an unenforceable "I Agree" button to terms nobody reads. What would be the best way to kill captive portals once and for all?
Whilst I hate Captive Portals in most circumstances (most hotels I stay at have completely broken implementations) we find them to be extremely useful.
We run LAN gaming events and a Captive Portal helps us enforce our physical check in procedure. If someone has somehow bypassed checkin, they have no access to our network... puts a bit of a downer at a LAN event.
You can do 802.1x user/pass auth. In general though it's far more expensive to run and maintain because your access layer (APs, switches etc) now needs to be fully managed to support 802.1x. That, and a lot of OSs have janky support that doesn't follow the standard well.
A properly designed captive portal can make it harder for someone leaving a small computer in the vicinity of your network and reverse tunneling through it for nefarious purposes. Having to log in every day would disrupt the tunnel and prevent remote access.
(Un)fortunately many captive portal are poorly designed, allowing arbitrary traffic to be sent over UDP/53 or ICMP, even when not authenticated. This kind of defeats the purpose of a captive portal, as the tunnel can be operated over UDP/53 (or whatever) and the captive portal can be solved remotely.
While those TOS button captive portals are definitely annoying, there are cases where this can be useful - for example, to enroll users for 802.1x certificates.
I am currently writing captive portal support for a big-name internet provider. This article only scratches the surface of how difficult it all is. Each OS is different, and each is painfully undocumented
Please don't build anti-features. They only happen because people like you and me agree to implement them. Push back against management. Tell them that you've done the research and it's a nightmare and you shouldn't move forward with it.
'They only happen because people like you and me agree to implement them.'
i am sorry, this is absurd line or reasoning. This logic has never worked in the history of business. It can only work in lisenced proffeshions like law and accounting where doing something nasty would loose you your lisence and your boss knows that, so literslly noone would agree to do it
secondly, captive portal at prague airport actually has a function - it provides you with up to date information about flights and dates.
The market for software engineers is very good. Many companies can't just cut you loose because you push back against an anti-feature. If they do, you have no shortage of other companies to work for.
You can provide flight information without a captive portal, just stick it on a normal web server. Maybe stick QR codes around the airport to help guide people to it. Bonus: you can access it outside of the airport.
As a thought experiment, if we want to use voluntary inaction to prevent bad ends, we have to go the distance. Standing alone won’t work , because companies can raise their rates until someone takes up the offer or they can lower their standards and pick up a dev without good prospects.
In order for this scheme to work, unions are needed. A professional union which like doctors associations would enforce ethical standards on its members and use collective bargaining to freeze malefactors out of the industry.
It wouldn’t be as good as how doctors have it, with legal weight and governmental recognition, but it would be enough.
This has worked many times. I have personally said "no" several times and many of my colleagues have as well -- and none of us were fired and none of the anti-features were built.
Operating a good wifi network at scale is usually quite costly. It is a good idea in some settings to be able to monetize outsized users. For example, your first 30 minutes on the airport wifi can be free, and if you have to be there for longer than that, you can pay a fee for the next hour.
How does a captive portal help with throttling or locking out users? Is the idea that the user could just recycle their MAC and be let in again, well the same thing applies for captive portals.
In general, someone needs to take a quick look it the development time and customer support involved really can be motivated from the extra earnings. The trend is that fewer and fewer bother, and just see complimentary wifi as a value add instead.
Airports, cruise ships, and other places where it does make economic sense are better served by real things like 802.11x and per-user QR codes.
That's not free, that's paying for it in a different way.
I do think the internet should be free, but how we sustain that is a pretty viable question. APs need to be installed, configured, and monitored. When spaces grow, APs usually need to be reconfigured or moved.
I know that airlines are fairly low margin businesses, based on what I've read from the recent bankruptcy stuff. I am curious about who owns airports and what their margins look like.
On mobile OSes, the captive portal is opened in a sandboxed embedded browser. OS designers want to prevent the captive portal from being used maliciously, so they understandably block off a lot of functionality. Problem is they don’t tell you what features they turn off. I.e As far as I can tell iOS blocks off external links and ajax requests (!)
On iOS you can’t close the captive portal programmatically. The user must submit an html form (or similar) and navigate to a new page. Only then will the OS check /mobile-hotspot-detect and realize that the user is connected to the internet and present the user a button to close the captive portal. This is very clunky and makes it impossible to make a sleek user experience
Android automatically closes the captive portal when it detects a connection. This often confuses the user (why did my page suddenly disappear?) and makes it impossible to make a consistent mobile captive portal experience between iOS and android
Androids kernel seems to have two separate, independent captive portal checks
iOS only checks the content of the connectivity check endpoint, while android also checks for any form of a DNS redirect in its requests
Microsoft checks against two different domains for a captive portal
Many Non-stock android distros check against their own custom (and undocumented) endpoints
There was a dhcp option recently introduced to help clean up this mess. Problem is, nobody supports it. Not even Apple (who seemed to have played a hand in the RFC) supports it
Linux is a lost cause
Figuring this all out took over a month of trial and error. Even then many of my conclusions are probably wrong. None of this is documented or standardized!
I've been there. I can relate to everything you said!
The DHCP standard was such a waste of time. Ignore it completely, no client support whatsoever.
Intercepting all plain HTTP traffic (just drop https) and responding with a 30x redirect to your captive portal web page seems to be the ad-hoc "standard". Your captive portal domain can be served under secured HTTPS just fine.
I fully agree with the sandboxed browsers pain and absolute impossibility to get a nice consistent UX across platforms.
Totally agree. Like you said the method we converged on is to just redirect DNS requests + 303 users depending on if they’ve gotten through the portal yet. It seems to work fine. What’s most frustrating is that most off-the-shelf FOSS dns programs don’t let you do DNS redirects on a per-mac basis, leading us to in-house a decent amount of DNS code.
I mean, captive portals started out as a hack, then captive portal detection was a hack against that hack... It's effectively an antagonistic relationship.
I currently live on a boat. Dealing with captive portal bs from the marine is always a nightmare. You have to buy the correct wifi extender/repeater otherwise you have to connect each device directly to the network.
If you just make sure you have something customizable enough (e.g. OpenWRT or some other reasonable dist) you can make detection-and-activation-scripts for portal types you encounter often enough. Some curl and whatnot in bash usually does the trick. I'm yet to find something that needs a headless browser or js runtime.
While bits and pieces of this can be found implemented in different repos, there seems to be a gap for a software which does this minimally and generally enough and could provide a base for the community to crowd-source profiles/configs/scripts.
I haven't dived into automating the captive portal yet. With my current setup I can access the captive portal from one device and it stays sticky to the whole network. I might look into automating it as the password changes monthly.
Can you use a smartphone, laptop, or any router running OpenWRT (in order from easiest to hardest) to simultaneously connect to the portal and rebroadcast the connection as a separate AP or Ethernet?
I built that on a raspberry pi with an additional USB wifi dongle. It can establish a VPN connection to my home router, too. The idea was that if I'm in a hotel where I have to pay per device, I can use many devices without extra charge plus I can access the Netflix catalog of my home country. Also, the captive portal support on the Fire TV stick used to be bad.
It worked with occasional hick ups, but in the last few years I could always use as many devices as I needed (usually two) for free, and the captive portal support on the Fire TV stick improved, so I haven't had the need for it anymore.
I am using an Alfa wifi camp pro 2. Which is basically a outdoor USB WiFi card going into a small Linux computer with additional wifi capabilities. That seems to do the trick. But I did try a few other out of the box solutions that did not work and had to do some research before settling in the Alfa.
Right now I am using an Alfa wifi camp pro 2. That then feeds into a Asus router. the Alfa is pretty much an outdoor USB WiFi card plugged into a small Linux computer with additional wifi and router capabilities. I also have an Alfa camp pro 4g as backup because the marina wifi is very unreliable. They have too many APs not setup correctly. The wifi is cox enterprises. Every now and then the captive portal resets and I have to enter the months wifi password, but stick to the Alfa card.
not OP but I’m using a GL.iNet travel router. It’s tiny. USB powered so can be plugged to a power bank. It has an Ethernet connection as well, can use your phone’s tethering as well. Great little gadget for travel.
I found the GL.inet gear underpowered, although I've only used their cheap stuff and finicky re: firmware -the last one had removed OpenWRT luci by default
The firmware is a huge mess and it's especially unfortunate that there seems to be some undocumented custom drivers or something else I haven't been able to identify yet which is missing from upstream OpenWRT, making it unusable for certain of their devices.
The gl.inet firwmare itself has a lot of missing updates and I am yet to successfully make custom builds of it (though in theory it should be possible through what's on their public Github repos, save for a handful of packages they provide as binary-only). They do not respond to issues or PRs on GitHub.
I should have taken better notes on building a firmware but I think what eventually allowed me to replicate and make custom build was to just build as if a normal openwrt dist from https://github.com/gl-inet/openwrt with a fork of https://github.com/gl-inet/gli-pub. Ended up ditching their custom hacky wireguard/tor functionality and mostly treating it as an openwrt dist.
Still stuck on a fork of the custom 19.07 (4.x kernel) for E750 (despite my efforts to bring it to 21.02). MT1300 doesn't seem to have had any issues on vanilla openwrt 21.02, though.
The mwan3 stuff can be worth keeping and extending on using the uci module, though.
It really is a shame as there are so many great things with the E750 and it has potential to be the perfect travel router. If there is anyone else who wants to take this to the next level, I could be down for making this ore structured and collaborate on making a more open, accessible, secure and hackable dist either just for the E750 or glinet in general.
To my shame, I must admit that I've implemented a captive portal before.
The article fails to mention https://datatracker.ietf.org/doc/html/rfc8952 and https://datatracker.ietf.org/doc/html/rfc8908 which get rid of most of the pain of captive portals on modern OS from a user perspective Still need to support Captive-Portal detection URLs for some edge-cases (Apple, MS, NetworkManager) and older desktops. But at least HTTP redirection becomes obsolete in almost all cases. Also has the nice feature of showing links to venue info page and remaining data volume in Android.
While I generally agree with the prevailing sentiment here I actually managed to implement a captive portal with surprisingly little trouble (ubuntu + haproxy). Use case was an offline WLAN where I needed to direct users through a specific flow / landing page. All up it was less than a day's research and work, plus the landing page build.
Please do!
I wanted to do something similar a few years ago and was shocked that I couldm't find any information on how to.
Of course I am also an amateur when it comes to this stuff, but it seemed to me a use case that could be common with SBCs like the raspberry pi and I was sad to not find an easy to follow write-up.
If I had access to a time machine, while I'd certainly kill Hitler and Stalin first and second, whoever invented the concept of a "captive portal" would end up dead before I ran out of bullets.
Just a stupid idea, badly implemented. So many places turned them on not because of any actual mandate from their legal department (how many places with captive portal pages actually have 'Legal Departments', anyway?) to do so, but because the feature was there in their routers, and thus it seemed like the "safe" thing to do. And once it became the standard thing for businesses to do, suddenly every business felt the need to do it. And now, people look at you like you're crazy if you suggest setting up a Guest WiFi network without one.
It's just too bad. This is literally why we can't have nice things.
The hidden assumption here is that using a CP doesn't actually give you at least some legal protection or at least an advantage if you end up in court.
Also, instead of blaming the restaurant owner who gets fire from all sides all the time, why not blame
- lawmakers and courts for not stating clearly whether using a CP is expected, or what the alternatives are
- OS, browser and access point vendors for inventing a more sane alternative than automated MitM attacks
What I don't see mentioned here is the issue to redirect the user from the captive portal browser back to its own (preferred) browser to display a landing page after acknowledging the TOS. On Android this seemed completely impossible and I noticed several implementations where there was simply requested to copy a link. On Apple any link with target blank would open a new Safari window. I'am wondering if this changed with later Android releases
I think apple is leaving money on the table. They could expect the captive site to return a meta element redirect to apple.com as most wifi portals return you back to the site it intercepted.
I often see the “Success” message and didn’t know that was defined by apple
I kind of hope one day personal data plans render public wifi obsolete. Every time you connect to a new wifi network you just never know what awaits. It might be a slow connection, it might be a shitty device that only kind of works, it might be a security nightmare… Wouldn't it be great if all our devices, laptops, tablets, mobile phones, had digital SIMs and we could just purchase a single data plan for all of them!
I think we're getting there in some countries, at least for "mobile" needs (read: when outside the home / office).
In France, I have a 40 GB mobile plan for €10. I know I'm likely below your average phone user, but the most I used out of this was about 4 GB when my home connection was dead, and I was working from home.
If I'm not mistaken, an 80 GB plan is less than €20. To me, that's basically unlimited.
I can get an extra SIM for €2 a month attached to the same plan. I never bothered because an internal WWAN card for my laptop is outrageously expensive, and since I don't need it often, I just share from my phone.
I used to be involved in the captive portal at Marvel Stadium in Melbourne (previously Etihad Stadium).
Usage is _very_ demographically aligned. At football games, we’d see connected device numbers somewhere around 10% of ticket sales. At a Justin Bieber show it was over 90%.
I have always had more mobile data available than I need, and I can’t remember the last time I bothered using a venue’s wifi (that wasn’t for work/testing purposes)
Back in the pre-Netflix days here I .au, I used to have a Raspberry Pi with a USB wifi dongle and a high gain antenna pointed at the local Mac Donalds - that’d monitor MAC addresses on their wifi waiting for one to stop transmitting, then it’d update its own MAC address to piggyback someone else’s T&C agreement, and run bit torrent until the connection ran out of its bandwidth quota, then it’d go back into monitor mode. I pirated the first couple of seasons of GoT ~500MB at a time that way…
I get your point, and actual unlimited plans would be just fine in my opinion. I've done remote work weeks completely from a phone connection, and on average I'd use between 1.2 GiB to 4 GiB per day for just work items depending on what I needed to do. This is chats, calls, RDP, and basic web browsing. Chats likely eat up a good amount of this, but even on good mobile internet, it's not feasible to do such items over a thin-client exclusively.
It'd be really nice if we could get to the stage where usage caps just weren't implemented.
Even more relevant perhaps : how many of these plans allow you to piggyback on the closest router's guest connection (from the same ISP) as long as you are in Wifi range. (Some of these routers even work as mini cell towers !)
I think that's usually the case, but it's not transparent. You'll have to connect to a specific SSID and enter some credentials which aren't always your usual credentials and / or use some app.
I've tried this once or twice a few years ago, but it was so slow that I went back to using my mobile plan.
No, it wouldn't be great. I don't care much about carrying a unique, trackable subscriber module everywhere, tied to a centralized billing system. WiFi has the advantage of being decentralized, and anonymizable. Not to mention the option of being free of charge.
Where I live in the US, the number of mobile providers outnumbers the number of wired ISPs that provide broadband speeds (even ignoring MVNOs).
I generally want to avoid replacing everything with mobile alternatives, but during a recent trip to the UK, I was pleased to find near-ubiquitous coverage via a basic SIM, purchased from a vending machine for £30 that gave me 100GB of data to use during the few weeks I was there. It was overkill, but I pay that much at home for 5GB data and I run into a lot more coverage issues.
And at least in theory, it's more likely for competitors to put up their own cell towers than it is to run new fiber alongside existing fiber (even if there aren't prohibitive franchise agreements in place) so I would definitely appreciate better mobile options here as well. Normally I'd never replace a fiber (or even cable) ISP with a mobile hotspot, but for travel, it negated the need to use public wifi for the entire 3 weeks I was traveling.
Indeed. This should really be the responsibility of the Wifi stack, which imposes the restriction and sits on a lower level than the HTTP stack. My gopher connections never work when I am behind a captive portal!
It is though. I've implemented a captive portal that uses this successfully for sending modern mobile OS like Android and iOs through captive portal. Marcos works fine too, also newer windows.
The WISPr[0] standard was created for this purpose, and is (or was by now?) used by companies such as iPass to their customers to transparently log in to most WiFi hotspots. I don't think that standard is accessibly anywhere these days. I made a Python implementation [1] that should still work.
There is a dhcp option that can be used as an alternative that was recently (~2yr ago) introduced but it’s not supported by any major OSes except android
Monsters don't exist. If people are really committed to erase anything that has the word "man" in it, at least they should try to be less lazy and use a term for people outside kindergarten.