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:


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.

  • slazer2au
    73 months ago

    I still have to investigate what limitation my browser has and whether I can update this whilst being trapped on an unrooted Android 5.

    Wait you are still using Lollypop? Your first priority should be to get on an android version from this decade. Lollipop came out in 2014 and went eos in 2016.

    As for your liability comment. I highly doubt the vendor had any liability or or requirement to support such on old os.

    • @[email protected]OP
      3 months ago

      Your first priority should be to get on an android version from this decade. Lollipop came out in 2014 and went eos in 2016.

      My first priority is to not financially support systems of premature forced obsolescence that has led to more smartphones in the world than people (despite ½ the world’s population having no smartphone at all). Buying a new phone just 6 years after another would make me part of the problem. I am writing this comment from a 16 year old machine that runs just fine. My AOS 5 device still uses the original battery. Only incompetence could explain inability of /software/ to outlive a /battery/.

      I cannot think of a more absurd reason to upgrade a phone than to keep up with captive portals. Apart from that, I must say that I may have to argue in court soon that I no longer have access to my bank account because my bank closed their website and forced people to install their closed-source proprietary app from Google Playstore. It will be easier to argue in court that the bank’s software does not run on my phone than it will be to say I have philosophical and ethical objections to sharing my phone number with a surveillance advertiser just to open an account just to fetch software, of which the non-freeness I also object to. So I am trapped on this phone for higher legal endeavors.

      When you say “this decade”, you’re disregarding the age and saying the line should be drawn at years that are multiples of 10. So a phone bought in 2019 would be “obsolete” in 2020 by your logic. Obviously that’s obtuse and reckless. I bought my AOS 5 phone new from the retail shop of a GSM carrier in 2018, 3rd quarter. It’s been in service less than 6 years.

      Apple is borderline reckless and they officially support phones for 10 years IIRC. And that limitation is imposed by the business bottom line. Capitalism aside, engineers who can’t make a smartphone that lasts 20 years would be lacking in competency.

      As for your liability comment. I highly doubt the vendor had any liability or or requirement to support such on old os.

      Captive portals are a messy hack. You do not need a captive portal to supply Wi-Fi in the first place. The suppliers do not advertise “we have a captive portal”. They advertise “Wi-Fi”, which my oldest phone (AOS 2.3) and my Nokia n800 (pre-smartphone) supports out of the box. They still connect to wi-fi today. You might be right that a pusher of forced obsolescence by way of incompetently implemented captive portal can argue in court that their advertising has immunity to old devices, but this won’t fool engineers who know they’ve needlessly drawn an arbitrary line. If the truth-in-advertising outcome would be that their “Wi-Fi” sign has to become “Wi-Fi available only for new phones”, I would be fine with that.