The red padlock (at a cafe)
The captive portal of a cafe simply rendered a red padlock on with a line through it. Essentially, it was apparently telling me I am being denied access arbitrarily without using any words. There was no other screen before that. Immediately after wifi handshaking Android’s built-in captive portal detection app just went straight to a padlock. I have never been in that cafe in my life and never use my device maliciously.
Showed the screen to the staff who said “works for me on my phone”, who then noticed the airplane on my status bar and said “oh, you got the little airplane, that’s the problem”. Shit; so then I had to explain that wi-fi works in airplane mode. It was just a distraction for them. I couldn’t really convince them that the problem isn’t anything I’m doing wrong. There is no tech support for this situation -- like pretty much all captive portal scenarios. Being the customer of the customer is a very weak position to be in when the direct customer doesn’t really give a shit if it works or not.
So, has anyone seen this kind of behavior? I run into shitty broken captive portals often enough that I guess I really need to get a better understanding of them, and ways to bypass them.
TLS-encumbered captive portal (transit service)
A transit service offered wi-fi but the network forcibly redirected me to a
captive portal that triggers this error:
net::ERR_SSL_VERSION_OR_CIPHER_MISMATCH
I tried a couple browsers and tried rewriting the https:// scheme as http:// but SSL redirect was forced consistently. The error apparently implies my phone’s browser can’t do TLS 1.3.
It seems like a shitty move for a transit service to require passengers to use TLS 1.3 just to tick a fucking box that says “I agree” (to the terms no one reads anyway). Couple questions:
-
I’m generally in the /protect everything by default/ school of thought. But I cannot get my head around why a captive portal where people just tap “I agree” would warrant disclosure protection that could hinder availability. In reality, I don’t really know what the captive portal at hand requests.. maybe it demands people’s phone# or email, in which case it might make sense (though I would object to them collecting that info in a GDPR region in the 1st place).
-
Is there a good reason for a captive portal to require TLS 1.3? It seems either the network provider does not trust their own network, or they’re simply incompetent (assumes everyone runs the latest phones). But if I’m missing something I would like to understand it.
I still have to investigate what limitation my browser has and whether I can update this whilst being trapped on an unrooted Android 5.
Bypass methods
I guess I need to study:
- ICMP tunnel (slow, but IIUC it’s the least commonly blocked)
- SSH tunnel
- others?
Are there any decent FOSS tools that implement the client side of tunnels without needing root? I have openvpn but have not tested to see if that can circumvent captive portals. I’ve only found:
- MultiVNC - VNC over SSH
- AVNC - VNC over SSH
- ConnectBot - Can all traffic be routed over this SSH tunnel, or just a shell session?
- VX ConnectBot - same as connectBot but expanded
I’m curious if the VNC clients would work but at the same time I’m not keen to bring in the complexity of then having to find a VNC server. Running my own server at home is not an option.
My to-do list of things to tinker with so far:
Legal options
If a supplier advertises Wi-Fi but then they render it dysfunctional by imposing arbitrary tech requirements after consumers have already bought the product/service it was included with (coffee, train/bus/plane fare, etc), then they neglect to support it, doesn’t that constitute false advertising? Guess this is out of scope for the community but I might be ½ tempted to file false advertising claims with consumer protection agencies in some cases.
And when a captive portal demands email or phone number, it would seem to be a GDPR violation. Some public libraries make wi-fi access conditional on sharing a mobile phone number which then entails an SMS verification loop.
update (phones bought last year already obsolete)
TLS 1.3 was not introduced until Android OS 10 (sept.2019). That was the release date of AOS 10. Older devices like AOS 9 would still be sold at that time and continuing at least into 2023. Shops do not pull their stock from the shelves when the end of support arrives. This means people buying new COTS Android devices just last year or even this year are already too out of date for the TLS 1.3 captive portal to function.
It’s seriously disgusting how many people expect consumers to upgrade this chronically fast.
Not in the slightest¹. It has reduced inclusiveness. The groups being excluded were previously given full and equal access. To argue that nighttime access is possible is to inherently advocate for exclusive access to those who would sit on the sidewalk with their device while people who need access by other means are denied. What a bizarre and obscure corner case. It’d be somewhat elitist to be selective like that. Human rights calls for equal access to public services (UDHR Art.21¶2). That means if a service cannot be offered to all demographics it should be offered to no one.
It’s really hair-splitting esoterics to be concerned about what library access there is at night time on the sidewalk. Maybe it’s fair enough to say outside of hours there is no sense of equal access. I don’t want to die on the nighttime access hill either way. My post concerns equality during the day when the library doors are open. If there really is a notable need for nighttime access from the sidewalk, that can also be deployed in an egalitarian way by mounting exterior ethernet ports and removing the captive portals.
(edit)¹ well, Wi-Fi in the 2000s was inclusive because it did not generally come with a captive portal and it was offered in parallel to ethernet. Having Wi-Fi is an essential part of being inclusive now that wi-fi-only devices exist. But the way they are doing it in 2024 is exclusive, depending on the library. Some libraries still today do not have captive portals but that’s becoming more rare as libraries prioritize a paperless agreement above equal access.
You’re thinking about the barriers and inconveniences to you personally. But when I speak about exclusivity, I’m talking about different demographics of people getting different treatment and different service. It’s unacceptible for a public service to say “sorry, some people just do not make the cut for the profile of those we are including.. our public service is only for people who subscribe to private GSM service” (precisely the demographic less in need of public service). It’s better to pull the plug to ensure equality than to create unequal access.
The DRM problem is not a problem of exclusivity w.r.t the public library, AFAICT, because the library secures whatever DRM rights are needed equally for all patrons. DRM does not cause someone who cannot afford a mobile phone to be refused service. Unless a DRM mechanism were to require an SMS verfication -- then I would be with you on that because that would be discriminatory and exclusive. Although I’ve heard that some forms of DRM prevent reading a page more than once. I can imagine that someone with an impairment of some kind might need to read a page more times than someone else to absorb the same book. In that case, DRM would indeed be adding to the exclusivity problem and would need a remedy in that regard. If a library could not negotiate an egalitarian deal in that case, then the egalitarian remedy is to drop that book from the library’s catalog completely, as that would ensure equal access.
It’s not a technical problem. It’s an ethical problem. When a public funded service is forces people to run proprietary non-free software on their own devices, it’s an abuse of public funding to needlessly force people into the private sector. In the US, the American Library Association has a bill of rights that states people are not to be excluded from the library based on their views or beliefs. Designing a library to only cater for people who are ethically okay with running non-free proprietary software would undermine that principle. It would be comparable to a public service denying service to vegans because of their ethical viewpoints.